[feat·M2] DecisionIntent memory — automatically record a live trade intent, then resolve it from execution evidence or one follow-up

[atomchung]

Status

Owner-approved product/implementation issue — separate owner, not an extension of #597. Not on the current M1 correctness critical path.

Owner ruling, 2026-07-30:

• A user who explicitly brings a live trade decision to FOMO Kernel has created an intent worth recording.
• The kernel should record that intent automatically; do not ask a separate “save this?” confirmation.
• A later transaction record is evidence that the action occurred.
• If no transaction evidence arrives, a later relevant interaction may ask once whether the user bought, did not buy, changed the plan, or is still considering it.

This issue owns that intent lifecycle. #597 continues to own the no-book conversational framing only. #490 continues to own execution-qualified decision memory and trade-event linkage truth.

Milestone

M2 — Recall and Compare My Reasons.

The write begins at the Phase-1 decision moment, but its value is longitudinal memory and later intent-versus-action reconciliation. Do not start this automatically while the current M1 correctness/answer-quality queue is active.

User outcome

A user can begin with no holdings snapshot or transaction history, discuss one real trade, and later return without reconstructing what they meant at the time.

The product can truthfully distinguish:

1. what the user intended / considered;
2. whether the user later reported acting;
3. whether a canonical transaction record proves an action occurred;
4. whether that transaction can be linked unambiguously to this specific intent.

Example progression:

“I am considering buying X as a small test because Y; I would exit if Z.”
→ DecisionIntent recorded automatically
→ later transaction import proves a buy occurred
→ unique compatible intent is linked, or one bounded mapping question is asked
→ later review can compare intended size/reason/exit with actual book and action

If no transaction evidence appears, the next relevant interaction may ask one bounded question:

“你上次考虑买入 X，后来有执行吗？”

The answer resolves the intent without pretending that a missing trade record exists.

Current behavior / evidence

Verified against main@dabf709 / PR #616:

• no-book DecisionFraming is host-side only;
• it has no engine call, session, route value, artifact or durable write;
• its three answers disappear with the conversation;
• a later snapshot or transaction import cannot recover the original intended importance, why_now, or exit condition.

Nearby owners do not cover this lifecycle:

• [research·product] Philosophy bootstrap: decision guidance before transaction history #597 / PR feat(contract): a decision with no recorded book is framed, not refused, and earns its next evidence (refs #597) (refs #617) #616 — asks the three questions and produces the bounded no-book answer; explicitly persists nothing.
• [feat·M1] Bounded TradeEvaluation with visible two-sided challenge #479 — persists a book-aware TradeEvaluation, i.e. a contemplated trade evaluated against a recorded book.
• [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490 — promotes an eligible evaluation into execution-qualified decision memory; it does not create a no-book intent record or own unresolved-intent follow-up.
• [arch·M2] Canonical bounded execution-qualified self-report history #450 — reads execution-qualified self-report history; it must not silently treat an unresolved intent as “why I acted.”
• [Phase 2] Not-Buy Tracker：沒買的決策也要記，30天後驗「不買對嗎」 #35 — old Not-Buy Tracker, closed not_planned. It proposed tracking broad watchlist/non-actions plus 30-day counterfactual P&L. This issue is narrower: only a trade the user deliberately brought into a real decision conversation, with no automatic opportunity or missed-return counterfactual.

Problem and consequence

The current stage-1 route creates useful decision context and immediately discards it.

Consequences:

• the next conversation repeats the same three questions;
• a later holdings snapshot cannot compare declared importance with actual weight;
• a later transaction cannot be tied back to the earliest reason and exit condition;
• “considered”, “reported executed” and “transaction-proven executed” remain indistinguishable outside the transient host chat;
• FOMO Kernel loses the first and often most decision-proximate memory supplied by a new user.

This is not primarily a storage shortage. It is a missing product/domain contract.

Decision

1. Automatic intent capture; no per-intent save confirmation

Explicitly invoking FOMO Kernel for one live trade decision is the product moment that authorizes local decision-memory capture. The host does not ask a second “save this?” question.

User control remains at the local data layer through status/export/reset/deletion mechanisms. Public GitHub evidence remains synthetic.

Only a deliberate trade-decision conversation qualifies. A ticker mention, news question, watchlist scan, or generic company research does not.

2. The stored truth is DecisionIntent, not profile or execution

The first record says only:

The user was considering this action and said these things at this time.

It does not say:

• the user executed;
• the declared target is an actual portfolio weight;
• the exit condition is an adopted permanent rule;
• the user has a stable investor style;
• the agent’s generated challenge is a user fact.

3. Minimum append-only contract

Use one versioned append-only stream with stable intent_id and event types such as opened, resolved, and superseded; do not mutate an original intent in place.

An opened intent minimally carries:

• intent_id;
• proposed instrument/action;
• exact user wording for intended importance/target size, why_now, and exit/invalidation where supplied;
• source route (decision_framing initially; do not duplicate an existing [feat·M1] Bounded TradeEvaluation with visible two-sided challenge #479 TradeEvaluation row);
• recorded_at and producing host/run provenance;
• bounded evidence references when explicitly supplied;
• status projection initially open;
• idempotency fingerprint so retries cannot append duplicates.

Agent-authored challenge prose is not canonical intent truth. It may be reproduced from source facts or stored separately as labelled judgment only after a concrete reader exists.

4. Resolution sources remain distinct

A resolution event records both status and authority:

• executed_trade_record — a canonical TradeEvent proves an action occurred and is linked to this intent;
• executed_user_reported — the user says they acted, but no canonical TradeEvent currently proves quantity/date/book consequence;
• not_executed_user_reported;
• modified — the original intent is superseded by a new one rather than rewritten;
• still_considering — remains open;
• unknown — no answer; never infer decline or expiry from silence.

A user-reported execution must not create a fabricated TradeEvent, holding, quantity, price or actual portfolio consequence. Later transaction evidence may upgrade the relation.

5. Transaction evidence proves action, but intent linkage may still be ambiguous

A transaction record is sufficient evidence that the recorded buy/sell occurred.

It does not always prove which prior intent or exact reason it realizes when there are multiple same-instrument intents, modified plans, partial executions or different quantities.

First-version rule:

• exactly one compatible open intent → link automatically;
• zero compatible intents → record the trade normally; do not invent an intent;
• multiple compatible intents → ask one bounded mapping question; never guess;
• a partial or modified execution may resolve the original as modified and create/link the final intent/premise according to [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490’s execution contract.

6. Follow-up is relevant-event triggered, not a background scheduler

When no transaction evidence resolves an open intent, ask at most one resolution question at the next relevant product moment, for example:

• the user returns to the same instrument;
• a new holdings snapshot or transaction file is ingested;
• a later review selects the unresolved intent as decision-relevant.

Do not create a timer, notification service, 30-day missed-return queue or broad watchlist sweep in the first version. Silence leaves the intent open.

7. First reader ships with the writer

Do not repeat #429’s write-only-memory defect.

The first implementation must include a visible reader that, on the next relevant interaction:

• retrieves the bounded open intent;
• avoids re-asking already captured facts;
• either upgrades the answer with actual book/transaction evidence or asks the single resolution question;
• clearly labels intent versus execution evidence.

A writer without this reader is incomplete.

Scope

This issue owns:

1. the DecisionIntent append contract and stable identity;
2. automatic no-book intent capture after a completed [research·product] Philosophy bootstrap: decision guidance before transaction history #597 framing;
3. bounded open-intent query;
4. one relevant-event-triggered resolution question;
5. intent resolution states and authority labels;
6. the handoff into [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490 when canonical TradeEvent evidence exists;
7. status/export/reset/replay and corruption/idempotency gates for the new stream;
8. same-session upgrade when a holdings view or transaction record arrives after the initial framing.

Non-goals

• No InvestorProfile, style label or personality inference.
• No automatic capture from every ticker mention, watchlist, news query or idea scan.
• No 30-day counterfactual P&L or “missed gain” judgment from [Phase 2] Not-Buy Tracker：沒買的決策也要記，30天後驗「不買對嗎」 #35.
• No shadow portfolio or assumed unexecuted position.
• No automatic broker matching when multiple intents are compatible.
• No claim that user-reported execution has canonical quantity, price or book consequence.
• No background scheduler, push notification or resident app.
• No permanent rule creation from an exit answer.
• No rewriting [feat·M1] Bounded TradeEvaluation with visible two-sided challenge #479 TradeEvaluation; avoid duplicate intent records for the same source decision.
• No use of unresolved intents as canonical M2 “why I acted” history.

Acceptance criteria

• A completed no-book DecisionFraming appends exactly one DecisionIntent without asking a save-confirmation question.
• Exact retry is idempotent; a materially different why_now, action or final premise receives a distinct identity.
• The original user statements remain byte-for-byte readable and are not rewritten by the reader.
• Intended size is labelled declared input and never emitted as actual weight.
• The next relevant same-instrument interaction reads the intent and does not repeat already answered questions.
• One unique compatible canonical TradeEvent automatically resolves and links the intent as executed_trade_record.
• Multiple compatible intents fail closed to one mapping question; no link is guessed.
• A user answer “yes, I bought” without a TradeEvent resolves as executed_user_reported and creates no trade/holding/quantity/price fact.
• “No”, “changed”, “still considering”, and no answer produce the distinct states above; silence never becomes not_executed or expired.
• A later canonical TradeEvent can upgrade a prior user-reported execution without rewriting the original events.
• An open intent is never surfaced as “why I acted” by [arch·M2] Canonical bounded execution-qualified self-report history #450 or profile input by [design·P1] The distillation layer: bounded profile memory over the append-only ledger (scoping) #446.
• Writer and first bounded reader land together; removing the reader makes a production-shaped test fail.
• Stream registration covers status/export/reset/replay; corruption and duplicate/conflicting resolution fail closed.
• Public fixtures and receipts use only fictional instruments, statements, dates and amounts.
• Existing [feat·M1] Bounded TradeEvaluation with visible two-sided challenge #479/[feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490 identity, TradeEvaluation, review and book-truth tests remain green.

Dependencies and relations

• Input/interaction contract: [research·product] Philosophy bootstrap: decision guidance before transaction history #597 / PR feat(contract): a decision with no recorded book is framed, not refused, and earns its next evidence (refs #597) (refs #617) #616.
• Book-aware contemplated-decision record: [feat·M1] Bounded TradeEvaluation with visible two-sided challenge #479 — reuse/query, do not duplicate.
• Execution truth and final promotion: [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490 — broaden its eligible source relation or provide a typed adapter; do not reimplement trade identity/link truth here.
• Execution-qualified history: [arch·M2] Canonical bounded execution-qualified self-report history #450 — unresolved intent remains a separate “what I considered” source, never “why I acted.”
• Roadmap/scope authority: [research·roadmap] Staged direction: pre-trade challenge → decision memory → rule learning #475. This owner ruling supersedes only its prior exclusion of automatically tracking a trade the user deliberately brought into a decision conversation; broad automatic tracking remains out of scope.
• Closed predecessor: [Phase 2] Not-Buy Tracker：沒買的決策也要記，30天後驗「不買對嗎」 #35 remains closed because its watchlist/30-day-counterfactual scope is not revived.
• Write-needs-reader precedent: [design·P1] Two questions collect an answer nothing reads: initial_thesis and exit_consistency (proved by a byte-identical card) #429.

Privacy boundary

Local-first durable memory. Real intents, reasons, exit conditions, transaction records and mappings remain in the user’s local data root.

Public repository issues, tests, PRs and QA receipts use fictional/generic data only. No private decision text, instrument, amount, date, source or reconstructable combination is posted to GitHub.

Rollout / compatibility / recovery

1. Slice A — no-book intent writer + bounded reader: append-only record, idempotency, same-instrument recall and one resolution prompt. No execution promotion yet beyond authority-labelled user response.
2. Slice B — canonical TradeEvent handoff through [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490: unique-match automatic link, ambiguity question, replay-stable resolution.
3. Later only if proven useful: a shared bounded “what I considered” query spanning no-book intents and existing TradeEvaluations without copying either source.

Legacy roots without the stream remain valid. Rebuilding the status projection from events must be deterministic. A failed append or resolution leaves the prior projection intact; partial files and conflicting resolutions fail closed. Rollback of Slice A removes the new reader/writer without mutating existing ledger, TradeEvaluation or execution-link records.

Stop condition

Stop after the smallest writer+reader slice and one owner-live trajectory prove that the next interaction is materially better: no repeated explanation, intent/execution truth stays separate, and the user can resolve or upgrade the intent in one bounded turn. Do not continue into profile distillation, rule learning, counterfactual P&L or background reminders.

[atomchung]

Owner ruling, 2026-07-31 — an intent is trade-shaped; the words attach to it but do not identify it

An earlier proposal in this thread made the user's own wording part of the intent's identity, so that a materially different why_now produced a distinct record. That is rejected. The owner's ruling:

理由上 intent 的結構應該跟其他交易應該是一樣的。時間、部位。原話可能也有,但是我覺得是時間部位是一個意圖。那我同意我們應該要保留原話,可以做未來更有彈性的判斷。

An intent carries the same skeleton as a trade — time and position — and the user's exact words attach to that skeleton as preserved evidence, never as its identity.

Three independent reasons this is right, all verifiable in the repository today:

1. Text-in-identity destroys this milestone's own outcome. M2's stated outcome is that "a changed reason is not automatically dishonesty or rationalization." If the reason is part of the identity, a changed reason produces a different intent — and "same intent, reason changed" becomes unobservable. The feature would delete the thing it exists to show.
2. The repository already splits it this way. trade-evaluation.schema.json composes a premise (the trade shape) and a separate context (reason / why_now / evidence_refs, decision-context.schema.json). The book-aware route has made this split since [feat·M1] Bounded TradeEvaluation with visible two-sided challenge #479. The no-book route has no reason to invent a second arrangement.
3. [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490 cannot link what is not trade-shaped. This issue's §5 hands execution linkage to [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490, whose candidate matching uses "ticker, side, date and quantity facts." An intent identified by prose cannot enter that matcher at all.

The full state space this record has to serve

The ruling came out of enumerating what can actually happen, which is two independent dimensions rather than a list of cases:

	transaction record proves it happened	no transaction record
stated beforehand	① stated and executed — reconcilable	② stated, execution unknown
not stated	③ learned only afterwards (today's normal case)	④ invisible

② and ③ are frequently the same event seen from two sides: the user states an intent, executes, and the CSV arrives later. When it arrives, ② + ③ collapse into ①. They can only collapse if both sides carry the same skeleton — otherwise the merge is a translation between two vocabularies rather than a comparison.

Quadrant ③ already exists in the product: initial_theses.jsonl, whose first offered choice is literally "I had a planned thesis" (copy/en.json:204). Today the product asks the user, after the fact, to recall whether an intent existed. Once ① exists that question has an answer already on file — which is a concrete question-budget saving under #291, not merely a friction improvement.

Verified constraints in the code today

Checked against origin/main@e198a86:

• A ledger trade event has no identity field. A row is {type, date, ticker, action, qty, price, market, currency, source_file} plus optional fee (engine/ledger.py:923-927). So the gap blocking quadrant ① is not only the missing intent — the trade side has nothing to point at either. This is why [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490's stable trade_event_id is a genuine prerequisite for identity-level linkage, and why fact-level reconciliation (_evaluation_reconciliation(), engine/review.py:6120) is explicitly "a fact, never a cause."
• occurred_at does not exist anywhere in this repository — zero occurrences under skills/. It is spec-only vocabulary in [arch·M2] Canonical bounded execution-qualified self-report history #450/[feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490/[feat·M2] Present execution-qualified previous/current reason comparison #487/[feat·M2] Append-only rationale refresh anchored to a position cycle #403. What exists today is type-specific: trade date, exit_date, observation.as_of, evaluation created. recorded_at does exist and is the settled spelling (engine/ledger.py:184-216); known_at has zero occurrences and must not be introduced.

Fields this issue's §3 contract does not yet propose, that a named downstream reader requires

1. voice / source-kind (user_verbatim | agent_interpretation | legacy_classification) — required by [arch·M2] Canonical bounded execution-qualified self-report history #450 and [feat·M2] Present execution-qualified previous/current reason comparison #487 on every returned item. This issue asserts the distinction in prose but stamps no machine-readable field. The repo currently expresses this idea four different ways (answers.schema.json summary_author, answer-provenance.schema.json provenance, and two schemas that are verbatim by docstring only) — a fifth would be a defect.
2. occurred_at, split from recorded_at — required by [arch·M2] Canonical bounded execution-qualified self-report history #450, [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490, [feat·M2] Present execution-qualified previous/current reason comparison #487, [feat·M2] Append-only rationale refresh anchored to a position cycle #403. Neither the opened event nor any resolution state here carries when the reported action actually happened.
3. A place on this stream to record the [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490 linkage (decision_id / trade_event_id). §5 hands off to [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490 but §3 lists no field to store the result, so a [arch·M2] Canonical bounded execution-qualified self-report history #450 reader assembling one list has no documented place to find it.
4. A concrete field for provenance. §3 says "producing host/run provenance" in prose only. [arch·M2] Canonical bounded execution-qualified self-report history #450, [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490 and [feat·M2] Append-only rationale refresh anchored to a position cycle #403 all use the same phrase — "producing workflow/run identity" — and this issue is the one that drifts.
5. A per-event identifier distinct from intent_id. [feat·M2] Append-only rationale refresh anchored to a position cycle #403's sibling contract requires engine-assigned event identity separate from subject identity. An intent whose resolution is first unknown and later real produces two resolved rows with nothing to tell them apart.

Naming collisions to settle before anything is written

• decision_id is already taken. engine/thesis.py:381-384,426 uses it for the content-hash identity of a thesis add-decision event — an unrelated concept. [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490's proposed ExecutedDecisionRecord.decision_id would make a repo-wide grep return two incompatible meanings.
• "source route" with value decision_framing: route already names a session-level enum (first_review | weekly_review | snapshot_review | test_drive, session-bundle.schema.json:52-59). Reusing the word for a per-record concept invites confusion.
• Schema version has three house spellings: v (ledger only), schema_version (everywhere else that has one), and no key at all (trade_evaluations, verdicts — both frozen-at-write leaf records, structurally the closest analogues to this stream). One must be chosen deliberately rather than by copying whichever file was opened first.

Design consequence

The owner's constraint for the next step is explicit: avoid adding more duplicated technical debt. The three-way schema-version split, the four spellings of "voice", and the type-specific time fields above are exactly the shape of that concern. The architecture proposal that follows will be reviewed by independent agents specifically for whether it re-creates something this repository already has, before any field is written.

[atomchung]

Independent review, 2026-07-31 — the architecture proposal was rejected, and two claims in my previous comment were wrong

Two independent reviewers (Codex, Gemini) reviewed a written architecture proposal for this stream. Both were pointed at one question — does this design re-create something the repository already has? — because the owner's stated constraint is that duplicated technical debt is already too high. Every finding below was re-verified against the code before being recorded here.

Corrections to my previous comment

1. voice is not new vocabulary. It already exists with incompatible values. schemas/question-opportunity.schema.json requires voice with enum: ["user_confirmed", "inferred"]. My previous comment listed four adjacent shapes and implied no field of that name existed; that was wrong. Adding a voice field carrying user_verbatim | agent_interpretation | legacy_classification would put two different meanings behind one name — the worst available outcome, and precisely the defect this review was run to prevent.
2. My _evaluation_reconciliation() line citation was wrong, and no line number is safe here. The function sits at a different line in every ref checked on the same day (5687 on one branch head, 6230 on origin/main@0af4866). Parallel sessions move this file constantly. Cite the function name, not review.py:<line> — a line number in an issue body is a cross-session communication defect waiting to happen.
3. I overstated what fact-level reconciliation can do. _evaluation_reconciliation() matches an open evaluation to the earliest trade with the same ticker and side inside a date window. It compares neither quantity nor price, and cannot name a trade event. It is therefore too weak to serve as the executed_trade_record proof this issue's §4 promises — that genuinely requires [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490's trade identity first, not merely as a nicety.
4. There are four schema-version spellings, not three. schema_version (13 occurrences), contract_version (2, in portfolio-basis.schema.json), ledger's v, and no key at all.

What the reviewers agreed on

• Do not persist voice or a generic provenance on this record. decision-context.schema.json already guarantees its text is the user's exact words and is never rewritten by the engine, so a reader can derive the voice. Both names already exist elsewhere with different meanings.
• Use schema_version, required on every event. Do not copy ledger v, and do not copy trade_evaluations' deliberate versionlessness — additive-only evolution does not cover a renamed field or changed enum meaning.
• The six-value resolution enum is wrong, but the two-orthogonal-fields fix proposed in the review was also wrong.

Where the reviewers went past the proposal

The enum conflates four axes, not two. executed/not_executed is an outcome; trade-record-versus-user-report is an evidence source; still_considering is an open-lifecycle reaffirmation; modified is supersession; unknown is the absence of a terminal event rather than a resolution result. Two free-standing enums would be more dangerous than one, because they admit invalid combinations a reader may not handle. The replacement is typed lifecycle events —

intent_opened
intent_reaffirmed          (replaces "still_considering")
intent_resolved            outcome: executed | not_executed
                           evidence: discriminated union —
                             {kind: trade_record, trade_id: ...}   (legal only with executed)
                             {kind: user_report, ...}
intent_superseded          supersedes/superseded_by intent id      (replaces "modified")

— with the union enforced in the hand-written validator, not only in the schema. The repository already does exactly this separation successfully: a condition check keeps the engine's result in engine_verdict, the adjudication in final_verdict, and who supplied it in verdict_source, and rejects invalid combinations.

Lifecycle ownership must not be duplicated. The proposal kept trade_evaluations.jsonl owning open|acted|declined|modified plus its own append-on-resolve reconciliation, and added a second stream with substantially the same lifecycle. Two files are acceptable when they protect distinct facts — this repository already separates condition identity from per-period condition events for that reason. Two state machines, two reconcilers, and two competing answers to "is this intent still open?" are not. DecisionIntent should become the sole lifecycle authority, with TradeEvaluation reduced to frozen computed evidence attached by intent_id. Existing decision rows are upcast conservatively in memory and never rewritten; in particular acted becomes a legacy value, never "executed with trade-record proof," because the current resolver attaches no execution evidence at all.

Identity was conflated with retry and with content. evaluation_id's content-hash pattern answers "is this the same frozen answer"; it cannot also answer "which append is this", "which aggregate is this", and "is this a retry". The established event-store separation applies: event_id for one immutable append, intent_id for the aggregate across events, an explicit idempotency_key supplied by the caller, and correlation_id where one command emits both an intent event and an evaluation. Cross-stream correlation is not recoverable after the fact.

Missing optimistic concurrency. Without a per-aggregate aggregate_version gated on an expected prior revision, two concurrent resolutions produce two heads. This repository already carries that debt knowingly — conditions.py's revision-chain reader tolerates forks because no write-side guard exists. A new stream should not reproduce it.

The one place the reviewers disagreed, and the ruling

Whether "when it actually happened" should reuse the existing as_of or introduce occurred_at.

as_of genuinely carries the right concept — "The date the figure describes, not the date it was read" — and appears in 17 schema locations, so my previous comment's claim that this concept does not exist in the repository was too strong. But every existing use binds it to an observed value: required: ["value", "as_of", "source"]. It dates a figure, not an action.

Ruling: keep them separate. as_of continues to date an observation; occurred_at dates an action — when the user stated, reaffirmed, or resolved the intent, and later when an execution occurred. recorded_at remains system-knowledge time per #472. Do not stamp occurred_at onto existing ledger rows before trade identity work is ready; a field with no reader is #429's defect.

Status

The proposal is not approved as written. Its reuse of trade-premise / decision-context fragments is sound; its identity model, duplicated lifecycle ownership, resolution model, and missing concurrency/idempotency contract are not. Revision comes before any writer is built.

[atomchung]

Owner rulings, 2026-07-31 — the durable unit is a position rationale, and this issue's proposed record type is withdrawn

A second review round, plus the owner's reframing of the domain, replaced this issue's central object. DecisionIntent — one record per contemplated trade — is withdrawn. What follows supersedes this issue's §2, §3 and §5 where they disagree.

The domain model

一個 ticker 其實就是一個進出理由 … 不管他給到我們什麼，可能 somehow 我們就都要整理出一個進出理由。那它本質上就是一個持倉理由

關鍵是一個持倉理由可能會對應到很多不同的交易。部位、進出場時間，用戶說的可能都會跟他們當初的預期有差異。

1. The durable unit is one position rationale per position cycle — not one record per contemplated trade. Owner ruling on cycle-versus-ticker: per cycle. A ticker fully exited and re-entered later is a new position with its own reason, and the previous rationale's exit is the ending of its own story, not something the next entry overwrites. Showing what a prior cycle said is a presentation concern ([feat·M2] Present execution-qualified previous/current reason comparison #487), not a reason to merge two cycles into one aggregate.
2. A rationale is revised, not multiplied. A user who discusses the same ticker repeatedly before buying produces one rationale with a revision chain, not N records. Every statement is preserved verbatim with its own date; what changes is that they form one aggregate with history rather than N parallel objects.
3. One rationale corresponds to many trades. Scaling in, averaging down and partial exits all roll up to it. Per-add decisions attach to the rationale; they are not themselves rationales.
4. Declared and actual will diverge, and the divergence is the content. What the user said about size and timing is a dated declaration and never becomes a computed weight. "You said a small test; it became your third-largest position" is the product's output, not an error to reconcile away.
5. A link between a rationale and a trade asserts sequence, never causation. The reason stays dated to when it was said. A long gap between statement and execution is recorded and stated plainly — no time window, no expiry, no special handling.
6. Ask only to collect data we do not have. Where transaction records exist, link automatically; never spend a question asking the user to confirm something already visible in their own data. The follow-up question in this issue's §6 is a fallback for a user who has supplied no transaction records — not a confirmation step.

Ruling 6 supersedes #490's "User confirmation is first-version relation authority" and its acceptance line "Exact confirmation creates one record; rejection/ambiguity creates none," for the unique-match case. The mitigation for a wrong automatic link is not a question but visibility: the link is stated in the answer and can be corrected. Automatic and silent would be fabrication; automatic and stated is not.

Why the withdrawn model was wrong

One record per contemplated trade means a single position accumulates many parallel "motives", which produces three defects that are one error wearing three hats:

• no answer to "which of these is the reason" at review time;
• [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490's "multiple compatible intents → ask a bounded mapping question" becomes the normal case rather than the edge case;
• [arch·M2] Canonical bounded execution-qualified self-report history #450's bounded-eight selection machinery (earliest + latest + six most recent, with total_count / shown_count / beyond_cap) exists to pick from a pile that the corrected model never creates.

Under one revisable rationale per cycle, at most one is open per position, so the ambiguity both issues spend paragraphs handling largely evaporates. #490 and #450 should be re-scoped against this model before either is implemented.

This is not new machinery — with one real gap

theses.jsonl is already the position rationale, and thesis_decisions.jsonl already holds the per-add decisions attached to it. Verified in engine/thesis.py: one thesis per cycle (stable_thesis_id), a revision chain (revises → prior last_event_id), aggregate identity distinct from per-event identity (thesis_id vs event_id), lifecycle status plus position_status, and evidence carrying claim / source / observed_at / falsifier / source_state. trade_recap.py supplies cycle_id and the in-cycle add cursor.

The gap is that a rationale cannot exist before its position does, which is exactly the cold-start case. An earlier draft of this comment claimed the fix was small — relax the birth condition and add a relink provenance kind. Independent review proved that too optimistic, and every blocker was re-verified against the code:

• cycle_id is not merely an id seed, it is the event stream's grouping key. Events are filtered by if isinstance(row, dict) and row.get("cycle_id"); the state dict is states[cycle_id] = row and is returned as [states[cycle_id] for cycle_id in sorted(states)]. A cycle-less rationale is not rejected — it silently vanishes.
• validate_thesis_updates requires the cycle_id to belong to a currently active position, so a pre-position rationale cannot be updated through the existing path.
• build_decision_events still falls back to stable_thesis_id(q.get("cycle_id")), so making identity opaque breaks a live lookup.
• thesis_cycle_relink cannot be reused: its eligibility requires origin == "snapshot", maturity == "inferred", source_confidence == "candidate" and provenance.kind == "snapshot_inference", and it presumes a prior cycle_id to move away from. It is snapshot-inference repair, not a general binding transition.
• The session bundle schema lists cycle_id as required on initial-thesis events.

The common root is that the aggregate's identity is derived from, and keyed by, the identity of the subject it describes. That is the same class of error as identifying a record by its content — an aggregate key must not be the thing the aggregate is about. The candidate direction is therefore to make thesis_id the aggregate key and demote cycle_id to an attribute that may be absent at birth and bound later. That is a refactor of existing code paying down an existing latent flaw, not a new subsystem — but its blast radius across readers is not yet established and is under review.

No implementation starts until that is settled.

[atomchung]

Second independent review, 2026-07-31 — eight blockers, one correction to my previous comment, and a minimum first cut that ships no UX

The second reviewer read the code rather than the proposal's paraphrase. Every claim below was re-verified before being recorded.

Correction to my previous comment

I wrote that trade_evaluations should be demoted to evidence attached to a thesis and should stop writing its decision lifecycle. That is wrong. _evaluation_reconciliation()'s own docstring opens with "For each folded evaluation still at decision: \"open\"" — the field drives the reconciliation that already works today, and --resolve's append semantics depend on it. An evaluation freezes something a rationale does not: one hypothetical trade's premise, book basis, computed consequence and two-sided case.

The correct integration is the reverse of demotion: an evaluation may optionally reference a thesis_id, and a DecisionContext may trigger a rationale's birth or revision. Neither record absorbs the other, and neither copies the other's consequence.

The blocker that is not a code problem

A durable rationale written with no book contradicts the product's own top-level contract in three places at once — AGENTS.md, skills/fomo-kernel/SKILL.md, and references/decision-framing.md all state that the no-book route makes no engine call and writes nothing durable, and _consider_rows() fails closed when the ledger has no events. This feature therefore requires an explicit amendment to those contracts plus a new legal CLI write entry point under boundary 7. It cannot be delivered as an identity refactor with the contracts left as they are.

Blockers verified in the code

1. thesis_id is not the aggregate key today; cycle_id is. reconstruct_states() filters events by cycle_id, indexes states[cycle_id], and returns one state per cycle. Making thesis_id opaque does not by itself let a rationale precede its cycle. Worse: relink today creates another cycle state carrying the same thesis_id while the old state persists — so "one rationale per position" is already not enforced by the fold.
2. A cycle-less row does not error; it disappears — and the disappearance can create a duplicate. Dropped from state reconstruction, the plan then judges an already-held position as missing a thesis and may open a second rationale for the same position. That is the precise opposite of the model this issue now adopts.
3. The user-visible wrong statement lands on conditions, not on the thesis. A condition pointing at a cycle absent from the live position index is classified as retired, and the card copy then declares the position fully out and the thesis ended.
4. thesis_cycle_relink cannot be reused for a first binding. Its guards require snapshot origin, inferred/candidate maturity, a single open ticker, no prior decision/exit/cursor, and a target cycle earlier than the snapshot. First binding after repeated discussion needs its own domain event — thesis_cycle_bound.
5. The lifecycle cannot express unbound or abandoned. A cycle-less rationale defaults to position_status: "open", and there is no state meaning "stated but never acted on."
6. initial_theses.jsonl currently converts sequence into causation. A cycle that already carries a draft or testable thesis is a no-duplicate rejection, so the entry-motive question is suppressed — meaning a pre-existing rationale, once bound, is silently treated as proof of the actual entry reason. Tests lock that suppression. This directly contradicts ruling 5 in the previous comment ("a link asserts sequence, never causation"), and the stream has no production semantic reader today.
7. Thesis presentation presumes ownership. The entry question says "You are holding", condition retirement says "fully out", every flow creates a thesis only for an open cycle, and light capture requires a cycle. An unbound rationale must therefore live in its own projection and must not be folded into active_theses.

Better news than expected

Making thesis_id opaque is cheap. There is no place in the repository that recomputes a thesis_id from a cycle_id in order to look up a stored record. All three call sites are generation fallbacks of the form prior.get("thesis_id") or stable_thesis_id(...). The work is redefining issuance and replay, not migrating a lookup surface.

Established practice

There is no standard event-sourcing pattern named "aggregate born unbound". The closest recognized shape is dynamic saga / process-manager association, whose documented failure modes are exactly the risks here: association ambiguity, concurrent duplicate binding, out-of-order delivery, and projection drift. The conventions to adopt wholesale rather than improvise: an opaque aggregate id, a separate association index, an explicit binding event, a uniqueness guard on the correlation, expected-version concurrency, command/event idempotency, and correlation/causation metadata.

Minimum first cut — engine only, no user-facing change

1. Fold by thesis_id instead of cycle_id in engine/thesis.py, and add explicit thesis_cycle_bound, unbound and abandoned states.
2. Build a separate cycle-association projection in engine/review.py rather than widening active_theses.
3. Declare the real event contract in schemas/session-bundle.schema.json.
4. Lock tests first for: rebuild with no cycle, first bind, retry idempotency, double-bind rejected, re-entry and abandonment, and legacy replay.

Only after that lands does the cold-start CLI entry point, coach/state registration, flow and copy changes, and the no-book contract amendment become a separate cut. No user-visible behavior changes in the first cut, which also means the first cut cannot be validated by dogfooding — its acceptance is the test set above.

[atomchung]

認領 Slice 1（引擎側）：把使用者在 consider 留下的原話，接到 first_review 的進場動機問題上。範圍是 _evaluation_recall + 問題產生器接線 + 三份 copy catalog + 測試；不動 thesis 聚合、不動產品契約、不開放 note 欄位。