loulou8063/thoughtport

thoughtport은(는) 무엇을 하나요?

Turn unstructured journal entries into a trustworthy routing draft. Let the user capture freely; make organization a review-time task.

Core contract

• Treat the user's notes as private source material, not content to publish or transmit.
• Preserve the user's language and distinguish it from external claims and quotations.
• Choose one canonical destination for each signal. Add a secondary destination only when a backlink creates real value.
• Base patterns on dated evidence and include progress or counterevidence.
• Draft first. Stop for approval before creating, moving, or editing vault files.
• Leave ambiguity visible under Needs Your Judgment; do not force a clean classification.

1. Choose the starting path

First determine whether the user has an existing Markdown or Obsidian workspace.

• If no workspace exists, or the user has never used Obsidian or defined projects, follow references/zero-to-first-review.md. Treat Obsidian as optional; a normal Markdown folder is sufficient.
• If a workspace exists, determine its root, review period, daily-note location, review-output location, and available destination files.

If thoughtport-config.md exists at the vault root, read it. If it does not exist or is incomplete, inspect the vault structure and follow references/onboarding.md. Propose any missing configuration instead of assuming a PARA, Zettelkasten, or other folder system.

Do not create configuration, starter files, or folders without approval.

2. Read the minimum useful context

Read completely:

1. Every daily note in the requested period.
2. The latest confirmed review, if one exists.
3. The user's current priorities, project index, or active-project briefs, if configured.
4. Notes directly linked from the period's journals when they affect meaning.

Read optional knowledge, decision, pattern, or influence indexes only when their modules are enabled or the current notes clearly require them. Do not scan the entire vault merely because access is available.

For historical backfills, use facts from the target period and only earlier confirmed reviews for comparison. Do not use future reviews or old AI drafts as evidence of what the user knew then.

3. Extract atomic signals

Split mixed entries into atomic signals while preserving a source backlink. Look for:

• observations, emotions, experiences, questions, and images;
• project progress, creative material, decisions, and next actions;
• external learning, quotations, and the user's response to them;
• repeated tensions, recovery evidence, changing behavior, and project drift;
• people or works that have a specific, evidenced influence on the user.

Record each signal with:

Signal | Source | Evidence type | Proposed route | Destination | Reason | Confidence

Separate an external author's claim from the user's reaction. Keep attribution with exact quotations. Never present an AI paraphrase as the user's settled belief.

4. Route the signals

Read references/routing-model.md before routing. Use four top-level routes:

• CREATE: advance a project, candidate, or creative work.
• UNDERSTAND: surface a decision, reflection, or evidenced personal pattern.
• LEARN: retain a source hook, active question, or durable understanding.
• INCUBATE: preserve a promising seed or unresolved item without premature commitment.

Prefer updating an existing project over creating a new one. Route by the signal's likely first useful outcome, not by every place it could theoretically fit.

5. Synthesize the review

Select only the two or three most consequential cross-note patterns. For each pattern:

• cite at least two dated observations unless the user explicitly named it as recurring;
• describe it as a current hypothesis, not a diagnosis or hidden root cause;
• include progress, interruption, or disconfirming evidence;
• explain why it matters now and suggest one proportionate next step.

Compare stated priorities with observed attention. Distinguish active avoidance—mentioned but repeatedly deferred—from absence, which may have many explanations.

Use assets/weekly-review-template.md for the draft. If configured, save it only to the approved drafts location; otherwise return it in the conversation.

Use the configured review filename pattern. If none exists, propose thoughtport-{start}-to-{end}.md and show the exact filename in the approval table before creating it.

6. Stop for approval

End the first pass after producing Suggested Moves — Awaiting Approval and Needs Your Judgment.

For every proposed write, show:

Source | Exact target | Proposed change | Reason | Confidence

Do not interpret “organize this” or “file this” as approval of ambiguous destinations. Apply only the items the user explicitly approves.

7. Apply approved changes

After approval:

1. Re-read each target before editing.
2. Append or merge without overwriting earlier interpretations.
3. Preserve source backlinks and attribution.
4. Avoid duplicate copies; use backlinks for cross-project relevance.
5. Mark an already-recorded signal as existing; propose no write unless the current period adds material evidence or changes its meaning.
6. Keep unapproved items in the draft.
7. Report exactly which files changed.

Before handling sensitive reflections or proposed writes, follow references/privacy-guardrails.md.

Guardrails

• Do not make mental-health diagnoses, infer sensitive traits, or claim certainty about motives.
• Do not treat a temporary emotion, ordinary task, or single mention as a recurring pattern.
• Do not promote a fresh external idea into permanent knowledge before the user has formed an attributable understanding.
• Do not turn every idea into a project or every influence mention into a profile.
• Do not overwrite journal entries, previous reviews, or historical interpretations.
• Do not call external services, browse, upload, or publish private note content unless the user explicitly requests that separate action.