[design·P1] A rule is the user's own standing expectation, not a review output — the loop, and what currently forces it through one door

[atomchung]

Status

Design discussion, owner-ruled 2026-07-31. Recorded so it is not re-derived. Blocks nothing; it reframes several open issues and should be read before spending on any of them.

The ruling, in the owner's own terms

Four points, given directly:

1. It is a loop. A rule is both a product of a review and the yardstick the next review measures against. Not either/or — the agent's first framing of it as one or the other was wrong. And a rule's inputs are many; the review card is only one of them. It is fundamentally a memory-shaped concept, not a card feature.
2. Discipline is supposed to accumulate.
3. You should be able to state a rule without running a review. At bottom it is the same question already on the table: do I have a preferred trading style, and what are my choices?
4. Research it, record it here, do not act yet.

Why this is #446's layer 2, not a new concept

#446's three-layer model puts "who this person is — cross-period behavior patterns, accumulated motives, trading personality" at layer 2, and #619 documents profile.md as that layer's first guess (2026-07-13, PR #183): a free-text file holding "trading goals + 3 personal principles, the reconciliation baseline for reviews."

Point 3 above is that layer stated in the owner's words. A rule is the most concrete instance of it the product already ships — and the only one that has ever had a persistence mechanism. So this is not a fourth memory concept; it is evidence about what layer 2 is actually for, arriving from a direction #446 did not come from.

What the product does today, measured on main@878c333

There is no way to state a rule without finishing a review. The CLI surface is prepare, resume, preview, finalize, capture, consider, refresh, positions, render, repair-projections, set-cap, mute-rule, add-cash, resolve-market-data, doctor. There is no add-rule. set-cap sets one specific numeric override and mute-rule silences an existing line; neither states a new expectation. A rule can only be born at a review's exit, one per review.

The rule store is not two competing sources. rules.jsonl is a rebuildable projection (references/data-contract.md), derived from the finalized session's commitment. consider reads the projection through problems.load_rules_report → consequence.rule_collision; the review lane reads the previous session's commitment directly. One canonical fact, two readers. That part is sound.

Only the most recent commitment is reconciled. Switch rules and the previous one's track record ends there — nothing accumulates about whether any rule worked, which is point 2 failing in practice.

The pre-commitment preview card exists because the rule is an output. Measured across three personas, the preview and the finalized card differ by 5 lines out of 53–63, and every one of those lines is the rule sentence (it appears twice on the card) plus its grounding sub-line. The product renders a whole second card to hold the place of one sentence. It has to, because the rule is produced by the flow it must appear in.

The "no rule change this period" nudge is never computed. card_renderer's no-commitment branch prints the continuity sentence unconditionally on every returning user's preview; nothing checks whether the engine actually proposes a change. Its own docstring describes the intended behaviour ("when the engine proposes no change it restates the standing rule") and the implementation never tests the condition.

What follows if a rule is a standing expectation

Stated as consequences to be evaluated, not as a plan:

• The preview card's reason to exist dissolves. Its job is to show the user a card before they supply the one thing the card is missing. If the rule is already standing, there is nothing missing, and the review simply reports against it. (The delivery-receipt job [feat·gate] Nothing stops finalize from committing a card the user never saw — the preview guarantee is instruction-only #628 established is separate and still needs an answer — but a receipt does not require a second full render.)
• fix(card): the standing-rule line names this period's prescription, not the rule the user actually committed to #645 changes subject. "The standing rule remains" is currently a false placeholder for a choice not yet made. Against a standing object it becomes a true statement. That issue may be repairing something that should not exist; do not implement it before this is settled.
• One rule per review stops being a natural limit. It is a property of the exit that creates them, not of what a person can hold themselves to.
• The review's purpose sharpens — from "here is your analysis, now pick a rule" to "here is how your stated expectations held up."
• consider is one reader, not the rule's home. Review, a single-trade look, and a pre-trade question are three occasions to consult the same standing expectation.

What is not decided here

• Whether rules stated outside a review are the same object as rules committed inside one, or a related-but-distinct kind.
• Where the standing set lives, given rules.jsonl is a projection and profile.json already holds standing preferences (mutes).
• How accumulation is expressed — a rule with a history, versus a chain of superseding rules.
• [design·P1] The distillation layer: bounded profile memory over the append-only ledger (scoping) #446's five open design questions. This constrains them; it does not answer them.
• [decision] profile.md 是記憶體系第 2 層的化石:退役、復活,還是等 #446 刀 2 搬家? #619's profile.md question (retire / revive / move under [design·P1] The distillation layer: bounded profile memory over the append-only ledger (scoping) #446 knife 2). This makes "revive as a free-text file" less likely and is worth reading alongside it, but does not settle it.

Evidence this changes something real

The 2026-07-29 diagnosis of "a review carries no payoff" concluded the cause was that nothing consumes the history. A rule is the one mechanism that does — and today it is reborn each review, reconciled only against its immediate predecessor, and cannot be stated at all except by completing a full review. That is the same finding, reached from the rule's side.

A real card from the shipped fixtures, for the record: a user committed to a 20% single-position cap, and the next review reads 當時 33%，這次 100%. The product states it in one sentence and moves on. Next period it will state it again. Whatever else this is, it is not yet discipline.

Related

#446 (the distillation layer this belongs to), #619 (profile.md, that layer's first guess), #645 (preview copy — hold), #628 (the delivery receipt the preview currently carries), #610 (the owner walk that can observe whether the engine's top-ranked candidate is the one a real user would pick), #429 (a question nobody reads is a defect).

[atomchung]

2026-07-31 follow-up — standing rules and holding rationale are sibling memory objects, not review outputs

Status: design clarification only. This does not unlock M2 or replace the current #610 M1 dogfood gate.

The owner’s question about holding motive exposes the same structural mistake this issue found for rules: the review currently looks like the place where memory is born, when it should be only one place that collects and reads it.

Two layer-2 objects, different lifecycles

Object	Meaning	Identity / history	Primary future reader
StandingRule	The user’s own expectation for how they intend to act	One stable rule line with revisions / supersession and an adherence history	review reconciliation, consider collision, later rule efficacy
PositionRationale	Why the user says they currently hold one position	Append-only statements anchored to one active position cycle; latest statement is a projection, earlier wording is never rewritten	next review, same-ticker consider, later rationale comparison

They belong to #446’s layer 2 because both describe durable personal context, but they must not share one record type:

• a rule is normative — “what I expect myself to do”;
• a rationale is descriptive self-report — “why I say I still hold this”;
• a mismatch between either statement and behavior is a separate Verdict event, never a silent profile/rationale rewrite ([design·P1] The distillation layer: bounded profile memory over the append-only ledger (scoping) #446’s three-object split).

Current product truth on main@9d56a2d

1. No standalone rule entry — already measured in this issue: the rule can be born only at review exit.
2. No standalone holding-rationale entry. The public CLI does have capture, but it is not a general user entry:
   • it requires an existing pending session whose cadence tier is light;
   • it can only attach to cycle ids already exposed by that Review Plan;
   • it ends by deleting the pending session;
   • it is therefore a light-review exception, not “tell FOMO Kernel why I hold X whenever I want.”
3. The light capture writes thesis_decision.note; thesis.reconstruct_states folds it into the active thesis state, so the bytes are not wholly unreachable. But the user-visible consumer is not guaranteed: [process·gate-debt] Disposition tracker: 34 fields the deepened QUESTION_CONSUMERS field-level check found unread across 4 sinks #480 records that thesis_decisions.note is unread by the card, and the current flow’s claim that the next full review will make the capture useful has no specific visible-reader acceptance.
4. A full review can collect several adjacent forms of motive (initial_thesis, add-decision note/evidence, headline_motive, inferred thesis), but their consumer quality is uneven ([design·P1] Two questions collect an answer nothing reads: initial_thesis and exit_consistency (proved by a byte-identical card) #429/[process·gate-debt] Disposition tracker: 34 fields the deepened QUESTION_CONSUMERS field-level check found unread across 4 sinks #480). More collection without one reader would deepen the same defect.

Product decision that follows

Rules and holding rationales should both be independently stateable outside a review. Explicit user initiation is already the authorization to write locally; do not ask a second “save this?” question.

But use two explicit domain actions behind the existing review.py facade, not one generic memory command:

• a standing-rule action updates/supersedes the rule line owned here;
• a holding-rationale action appends a position-cycle self-report owned by [feat·M2] Append-only rationale refresh anchored to a position cycle #403/[arch·M2] Canonical bounded execution-qualified self-report history #450.

Command spelling is intentionally not decided in this comment. The contract matters first.

The review’s new relationship to memory

A review becomes a reader and selective collector, not the aggregate root of either object:

1. Load the active standing rules and latest rationale for relevant position cycles.
2. Do not re-ask facts already on record.
3. Ask about a rationale only when the answer can change this review — material new trade, condition crossing, horizon/event, stale statement plus a meaningful position change, or behavior/self-report conflict. Engine supplies those facts; agent chooses relevance inside the question budget ([feat·M2] Append-only rationale refresh anchored to a position cycle #403 ruling).
4. Append the user’s new exact wording through the same rationale writer used by direct entry.
5. If behavior contradicts the stated rationale/rule, append or surface a separate verdict; never rewrite the source statement to make it match behavior.

Why direct rationale entry creates real user value

A user should be able to say, outside any review:

“我现在继续持有 X，是因为 Y；如果 Z 发生，我会认为原判断失效。”

The immediate receipt is small, but the future reader is concrete:

• next review starts from Y instead of asking from zero;
• a checkable Z enters the existing condition machinery; an uncheckable reason remains verbatim and explicitly unmapped rather than being pretended monitored;
• a same-ticker consider can contrast today’s add/reduce reason with the current holding rationale;
• later review can compare stated rationale with actual hold/add/exit behavior without calling an unexecuted intent “why I acted.”

Scope / routing

• [feat·M2] Append-only rationale refresh anchored to a position cycle #403 / [arch·M2] Canonical bounded execution-qualified self-report history #450 own the rationale append contract and bounded reader. Direct user entry should be a second entry into that same writer, not a new store.
• [design·P1] A rule is the user's own standing expectation, not a review output — the loop, and what currently forces it through one door #650 continues to own standing-rule lifecycle, independent entry and accumulated adherence.
• [feat·M2] DecisionIntent memory — automatically record a live trade intent, then resolve it from execution evidence or one follow-up #636 owns no-book live trade intent; do not store that as a holding rationale before a position exists.
• [feat·M2] Explicit execution link promotes an evaluation into durable decision memory #490 owns execution truth; a rationale or intent never fabricates a trade.
• [design·P1] The distillation layer: bounded profile memory over the append-only ledger (scoping) #446 owns behavior-derived profile labels and verdicts; self-report alone never becomes “the user is a momentum investor.”

The common invariant is:

Review, direct chat and pre-trade discussion may collect the same domain fact, but one domain fact has one canonical writer and at least one named future reader.

[atomchung]

Sequencing update, 2026-07-31

The owner approved the PositionRationale sibling (#403/#450) to proceed in parallel with #610. This does not activate standing-rule implementation here.

Current order:

1. [QA·dogfood] Judgment-quality dogfood — does a real consider answer now carry a supported insight? #610 frozen dogfood continues.
2. [feat·M2] Append-only rationale refresh anchored to a position cycle #403 first vertical slice: direct rationale → next-review reader, with [bug·design·P2] Every new snapshot declaration re-asks for theses it was already given #539/[bug·design·P2] A review-lane anchor adoption spends the user's holding-duration answer #536 identity continuity.
3. Revisit [design·P1] A rule is the user's own standing expectation, not a review output — the loop, and what currently forces it through one door #650's independent rule entry and accumulated adherence after that memory path proves the one-writer/one-reader pattern in live use.

Reason: implementing both sibling memory lifecycles at once would create two new canonical writers and two UX changes before either is owner-accepted. #403 is the smaller proving slice because it already has a named position subject and a concrete next-review reader. The rule questions listed in this issue remain open and unchanged.

[atomchung]

Decision workshop — split the standing-rule lifecycle into three owner choices

Status: discussion only, not an owner ruling and not permission to start implementation.

R1. Are rules stated inside and outside a review the same object?

Option R1-A — separate rule kinds

A review commitment and a direct personal rule live as different objects.

User experience:

• preserves current implementation with less migration;
• but the user can end up with two semantically identical rules, one consulted by review and another by direct chat;
• changing one may not change the other, so “my rule” stops being a single truth.

Option R1-B — one StandingRule, different capture sources

Review suggestion, review commitment and direct statement all create/revise the same domain object. capture_source records where it came from; the user's explicit acceptance is what activates it.

User experience:

• “my rule” means the same thing everywhere;
• review can suggest without auto-saving, and direct chat can state one without a review;
• later review and consider consult the same standing set.

Recommendation: R1-B. Multiple entrances, one canonical writer. This is the same boundary approved for PositionRationale.

R2. How are multiple rules and changes represented?

Option R2-A — one global active rule

User experience: very simple, but adopting a holding-period rule silently ends a sizing rule. The current one-rule-per-review constraint becomes a permanent product limitation.

Option R2-B — unlimited flat active rules

User experience: expressive, but attention and collision output become noisy; contradictory rules can coexist with no resolution.

Option R2-C — multiple stable rule lines, one active revision per line

A rule line represents one continuing expectation/dimension. Rewording or changing its threshold appends a revision/supersession on that line. Different compatible lines may coexist, such as position-size cap and minimum holding period. Two active rules that govern the same subject/dimension and conflict fail closed to a clarification.

User experience:

• the user can keep several real disciplines;
• “change my 20% cap to 25%” updates the same history rather than creating a duplicate;
• review can focus on the materially relevant one instead of printing every rule.

Recommendation: R2-C. It preserves continuity without turning the rule set into an unbounded checklist.

Canonical direction: a dedicated append-only standing-rule event stream should own direct and review-created rules. rules.jsonl remains a rebuildable projection, and profile.json remains preference state such as mutes/cap override; neither should become a second canonical rule writer. A finalized review references the accepted rule event id.

R3. What does “discipline accumulates” mean?

Option R3-A — keep only the latest comparison

This is close to today. User experience: “last time 33%, this time 100%,” but switching rules ends the track and no denominator exists.

Option R3-B — mutable counters on the rule

User experience: shows a streak/rate cheaply, but replay cannot explain which opportunities counted; corruption or rule revisions make the aggregate hard to recover.

Option R3-C — append one check per eligible opportunity, then fold

Each RuleOpportunity/RuleCheck freezes:

• rule line and revision used;
• why this was an eligible opportunity;
• observed behavior/evidence;
• followed / breached / unknown / not-applicable;
• basis/time and any user-resolved exception.

The UI folds these into a bounded summary such as:

“This rule applied five times; you followed it four times. The one exception was the add you explicitly marked tactical.”

User experience:

• discipline becomes a history the user can inspect rather than a slogan;
• unknown/incomplete evidence does not count as breach;
• later rule efficacy can use the same denominator without fabricating portfolio counterfactual P&L.

Recommendation: R3-C. It is the only option that makes accumulation auditable. It belongs after the standing-rule object and opportunity definition are stable.

Suggested owner choices

Recommended package: R1-B + R2-C + R3-C.

Resulting experience:

• user states a rule anywhere;
• review may suggest a rule but activates it only after acceptance;
• multiple compatible disciplines coexist;
• revisions preserve history;
• review reports adherence against eligible opportunities rather than asking for a new rule every period.

This remains separate from #403 implementation and should not start automatically.

[atomchung]

Owner rulings — 2026-07-31: one StandingRule object, stable lines with revisions, opportunity-based adherence

The owner chose B / C / C from the standing-rule decision matrix.

1. Review and direct entry create the same object — choose B

There is one canonical StandingRule lifecycle. Review suggestion, review acceptance and direct user statement are different capture sources/readers, not different rule kinds.

A review may propose a rule, but it becomes standing only when the user accepts/states it through the same canonical writer used by direct entry. consider and later reviews consult that same standing set.

2. An explicit user threshold replaces the product default

Owner example:

如果用戶願意持倉 25，應該要取代預設 20。

Therefore an explicit 25% single-position cap is one active revision of the sizing-cap rule line and replaces the suggested/default 20% threshold for that user. It is not a second simultaneous 20% + 25% rule, and behavior must never be used to infer the personalized cap.

This preserves the existing set-cap product behavior documented on main: explicit profile.json.max_position_pct overrides the universal default until cleared. The future StandingRule canonical lifecycle must absorb/re-home that preference without changing its user-visible meaning or losing it during projection repair.

Clearing/superseding the explicit cap returns to the universal default; it does not rewrite history to claim the user always used 20%.

3. Multiple stable rule lines, one active revision per line — choose C

Different discipline dimensions may coexist, for example:

• position sizing cap;
• minimum holding period;
• averaging-down constraint.

Each line has stable identity and append-only revisions/supersession. A new value on the same line replaces the active revision; it does not create two contradictory active thresholds. The review selects only relevant lines for attention and does not print the full standing set every time.

4. Adherence accumulates through eligible opportunities/checks — choose C

Do not store only mutable counters and do not compare only with the immediately prior review.

For each engine-proven eligible opportunity, append a RuleCheck/equivalent event that freezes at least:

• rule line + active revision evaluated;
• eligible subject/opportunity and basis;
• followed | breached | unknown | declared_exception | not_applicable or a deliberately equivalent closed state set;
• evidence references and observation time;
• whether the outcome is user-confirmed or mechanically determined.

A fold may present 4 of 5 eligible opportunities followed, but the denominator and each event remain auditable. Missing/incomplete data must not become a breach, and a declared exception is not silently counted as compliance.

User-visible result

The product can eventually say:

你目前的單一持倉上限是 25%，已取代預設 20%。這條紀律過去適用 5 次，其中 4 次遵守；另一次是你明確標記的例外。

instead of rebirthing one rule per review or losing its history when the active prescription changes.

Still open before implementation

These rulings close the object/unification, revision and adherence directions. A later implementation design still needs to freeze canonical storage, migration from session commitments / profile.json, opportunity eligibility per rule type, conflict handling across rule lines, and owner-live acceptance. Do not start this implementation merely because #403 is active.