[bug·design·P2] Every new snapshot declaration re-asks for theses it was already given

[atomchung]

Privacy boundary

Public design leaf. Synthetic fixtures only.

What a user hits

They declare their holdings, and the review asks them to state a thesis for each position. They write them.

Next time they declare holdings, they are asked for the same theses again. The ones they already wrote do not carry over.

Why

A snapshot-derived cycle id is ticker#<as_of>#<seq> — the declaration's own date is part of the identity. So every new declaration mints new cycle ids for the same continuously-held positions, and missing_thesis_positions correctly reports that none of them has a thesis: the theses on file are bound to the previous as_of's ids.

The engine is not wrong about anything here. Each id honestly names what it names. Nothing joins the two generations of ids for a position the user never stopped holding.

Scope, established rather than assumed

Observed on a plain second declaration with no refresh involved, so this predates and is unaffected by #530 and #531. It is a property of snapshot-derived identity, not of the book-update lane.

Why it belongs on the payoff line, not the correctness line

Nothing is computed wrongly and nothing is lost from disk. What is lost is the user's work: they answered, and the product asks again as if they had not. That is the same defect class as #429 — attention collected, nothing kept — and it lands on the most effortful thing a review asks for.

It also compounds with the finding behind the review-payoff work: a user whose second review repeats the first review's conclusion and re-asks its questions has no evidence the product remembers them at all.

Fix shape (not decided)

The load-bearing question is what identity a continuously-held, snapshot-declared position should carry across declarations — the current as_of-derived id is right for "this is what was declared on this date" and wrong for "this is the position I have held since March". A relink is one shape; a stable per-position identity with the declaration date as an attribute rather than a component is another.

Decide it with #536 and #532: all three are the same question in different clothes — what survives an adoption, and what is the identity it survives against.

Acceptance criteria

• A position held continuously across two declarations is not asked for a thesis twice.
• A position genuinely sold and re-bought still opens a new cycle and is asked (the invariant [design·M0] A position appearing in a newly declared book is confirmed, like one disappearing #531's carry-forward already holds on the refresh side).
• Proven by a test whose mutation fails.

Refs #429, #532, #536, #486.

[atomchung]

Sequencing ruling — 2026-07-29

Deliberately not a blocker for #486. The owner ruled that hitting this during the M0 owner-live acceptance walk is a noted finding, not a gate failure, so M0 can exit on its own outcome (current-book correctness and delivery) rather than on cross-period memory. Same ruling recorded on #486, which is the issue someone actually reads while walking.

That is a sequencing decision, not a downgrade. Two things about this issue are unchanged:

• It stays the top-ranked agent-executable item in tracking: current context index — milestone, critical path, what an agent may pick up #27's queue, because it is the most likely thing to make a real second review feel like the product has no memory.
• Its fix touches snapshot-derived cycle identity, which is not a small change. It should be picked up as its own slice with its own review, not folded into an M0 patch.

The honest reading of the ordering: M0 exits first because its outcome does not depend on this, and this gets fixed properly rather than quickly.

[atomchung]

2026-07-31 dependency update — snapshot cycle continuity is now the enabling identity leaf for #403

The owner approved #403 (direct/periodic holding-rationale memory) to proceed in parallel with #610. That capability is anchored to an active position cycle, so this issue is no longer only about repeated thesis questions: it is the identity prerequisite that prevents a newly recorded rationale from disappearing on the next ordinary snapshot declaration.

Chosen direction

Preserve the existing position-cycle model; do not introduce a generic memory subject id in #403.

Build one shared engine-side carry-forward/relink primitive for snapshot adoption:

1. same ticker + market + currency, continuously held through the prior recorded book and new declaration → preserve/alias the prior cycle lineage;
2. confirmed disappearance/sale followed by re-entry → new cycle; no thesis/rationale inheritance;
3. ambiguous continuity → fail closed or leave unlinked; never join by ticker alone;
4. both refresh-lane and review-lane adoption call the same primitive, which also closes [bug·design·P2] A review-lane anchor adoption spends the user's holding-duration answer #536's two-lane provenance loss rather than hand-mirroring it;
5. a later transaction-history upgrade that discovers an earlier start ([design] A snapshot-inferred cycle start is now final — the relink that let a later CSV correct it rode on the completeness flag #549 removed #563) emits/retains a relink alias, so domain memory remains reachable even if the display cycle start improves.

The user-supplied snapshot envelope remains facts-only. Cycle/provenance carry-forward is engine-owned during adoption; the agent never authors cycle identity.

Scope boundary

This issue still owns identity continuity, not the rationale stream or reader. #403/#450 consume the relink result. Do not append rationale rows here.

Acceptance additions

• A rationale/thesis attached before an ordinary second snapshot remains attached after adoption.
• A sold-and-rebought position does not inherit it.
• Refresh and review adoption use one implementation.
• The relink/continuity output is replay-stable and survives projection repair.
• A mutation that remints the cycle on every snapshot makes both this issue's original thesis test and [feat·M2] Append-only rationale refresh anchored to a position cycle #403's rationale-memory trajectory fail.

Parallel development boundary

This identity leaf may run in parallel with #403's schema/store/query module because the file ownership can remain disjoint. review.py integration waits until both stabilize.

Refs #403, #450, #536, #563, #610.

[atomchung]

Design review before implementation, 2026-07-31 — the shared primitive is necessary but not sufficient, and the seam is one layer lower

Reproduced on main@d4c7d2e through the CLI, with synthetic fixtures only. Three findings change this front's scope; a fourth fixes the shape of the fix.

1. The one-shared-primitive plan does not close this issue

book_refresh._carry_forward_provenance is gated on a stamp:

stamp = (recorded.get(ticker) or {}).get("since_basis")
if stamp not in lg.SINCE_BASES:      # ("user_estimate", "unknown")
    return row

A stamp only ever exists for a position the appearance question was asked about, and that question is only asked for a position that appears after the book exists (#531). Every position in the user's very first declaration is therefore permanently unstampable — there is nothing to carry, and it re-mints on every later adoption, in both lanes.

Receipt, refresh lane, which already has the primitive:

after 1st declaration : ACME#2026-06-30#1  WIDGET#2026-06-30#1
(refresh adopts a later declaration in which NEWCO appears and is stamped)
after adoption        : ACME#2026-07-15#1  WIDGET#2026-07-15#1   ← untouched positions, new cycles
                        NEWCO#2025-05-15#1                        ← stamped, correctly preserved

So unifying the two lanes closes #536 and leaves this issue exactly where it is. The carried fact has to be since itself, not only the stamp.

2. A second symptom of the same root cause: a declaration overwrites a proven start

Not only the unstamped snapshot case. A position opened by a real trade after the anchor carries a ledger-proven cycle start, and the next declaration discards it:

snapshot(2026-06-30) + buy NEWCO(2026-07-05)      → NEWCO#2026-07-05#1  origin=trades
+ ordinary second declaration (2026-07-28)        → NEWCO#2026-07-28#1  origin=snapshot

Here the engine knew the answer and replaced it with a bookkeeping date. Per the standing rule that a second recurrence of a symptom is a design problem rather than a second patch, this belongs in the same cut, not in a follow-up.

3. Root cause, stated once

ledger._anchored_cycle_start defaults an anchor position's start to the anchor's own as_of, and cycle_id = f"{ticker}#{since}#{seq}". So every re-declaration regresses a start the record already held to the newest declaration date. Today's value is not merely unstable, it is the less true of the two available lower bounds.

4. Proposed decision — carry the recorded start, one new engine-only since_basis

Preserve identity rather than alias it:

• ledger.SINCE_BASES gains one value the engine alone may author — proposed recorded_book, meaning "this start came from the book already on record and this declaration did not restate it". It sits beside user_estimate (a claim the user made) and unknown (the honest gap), and _anchored_cycle_start reads it exactly like user_estimate.
• One adoption primitive computes, per supplied position, from the derived book rather than from the last declared anchor:
  • recorded stamp user_estimate / unknown and the record still traces the position to the anchor → carry the stamp (today's behavior, unchanged);
  • otherwise, if the position is in the derived book → carry that book's own since, stamped recorded_book;
  • not in the derived book → untouched; it is appearing, and [design·M0] A position appearing in a newly declared book is confirmed, like one disappearing #531 owns it.

Reading since off holdings_as_of rather than off the previous anchor's stamp removes the sold-and-rebought hazard instead of gating around it: a rebought position's derived since is the rebuy date, so there is nothing to inherit. The existing origin == "snapshot" gate stays, but only on the stamped branch, where it is still doing its original job of not spending the user's #531 answer on a different cycle.

The value is a fixpoint — carrying it again yields the same date — so replay, repair-projections and an idempotent finalize retry are stable by construction rather than by care.

5. The seam #536 proposes costs more than one a layer lower

#536's fix shape ("thread the prior anchor into snapshot_adapter.prepare, plus a call reordering") collides with a gate this repository already has: tests/test_book_refresh.py::test_only_the_refresh_lane_may_write_engine_assigned_provenance asserts users == {"book_refresh.py": 1} — exactly one allow_engine_provenance=True call site. Threading it into the adapter adds a second privileged writer of a cycle start.

Instead: the primitive lives in book_refresh.py and is the sole privileged call site (build_adoption calls it rather than holding a second copy), and the review lane calls it in cmd_prepare on the normalized envelope before snapshot_adapter.prepare builds anything from it. No reordering of _refuse_if_the_book_must_catch_up is required — provenance keys never enter snapshot_reconciliation's diff (shares / market / currency / avg_cost only), so the refusal decision is unaffected.

That placement also gives the review lane one computation with two consumers instead of two derivations: snapshot_adapter._anchor passes provenance into the ledger anchor, and _state_positions derives the plan's cycle ids from that same anchor. Stamp once, both surfaces read what was stamped.

6. Why this closes the acceptance criterion with no change at the question layer

review.py:3802 is the whole re-ask:

missing = [_missing_thesis_entry(ticker, row)
           for ticker, row in sorted(positions.items()) if row.get("cycle_id") not in active]

A stable cycle_id makes the position find its thesis. Nothing in the question layer, the thesis writer or the card needs to know this fix happened — which is the strongest argument for identity preservation over aliasing.

7. Consequence for #403 / #450, and for the parallel plan

#27 declares Fronts A and B parallel on file disjointness, but #450's frozen reader contract says the reader "follows engine-proven cycle relinks/carry-forward aliases" — that presumes an alias producer, and which shape this front lands decides whether that clause has one. It is a contract dependency, not a file dependency, and it has to be settled before either front writes its fixture. With the decision above:

• an ordinary re-declaration produces no alias at all — the cycle id is literally unchanged, so [feat·M2] Append-only rationale refresh anchored to a position cycle #403's subject identity stays valid without a chain walk;
• aliases remain only where the start genuinely changes, which is [design] A snapshot-inferred cycle start is now final — the relink that let a later CSV correct it rode on the completeness flag #549 removed #563's later-history upgrade, already produced by thesis.build_snapshot_cycle_relinks;
• [arch·M2] Canonical bounded execution-qualified self-report history #450's reader still needs alias-following for that path, and its shared fixture should cover the unchanged-identity case as the common one and the relink as the exception, not the other way round.

Acceptance additions this review implies

• A position present in the first declaration and never sold keeps its cycle id across an arbitrary number of later declarations, in both lanes.
• A trades-origin position keeps its ledger-proven start across a later declaration.
• A sold-and-rebought position still opens a new cycle and inherits nothing.
• The carried value is stable under replay and repair-projections (carrying twice changes nothing).
• The mutation that remints on every declaration fails the review-lane test, not only a unit test.

---

Generated by Claude Code

[atomchung]

Maintainer disposition — accept identity preservation and the lower seam; revise the proposed provenance value before implementation

Re-checked the reported mechanism against main@47db263:

• book_refresh._carry_forward_provenance only carries a start when the recorded row already has a since_basis in ledger.SINCE_BASES;
• ledger.SINCE_BASES is currently only user_estimate | unknown;
• positions from the first declaration and trade-derived starts therefore do not qualify for carry-forward.

The review at #539 (comment) is correct that merely sharing today's stamped-only helper across two lanes would close #536 but leave #539 open. It is also correct that a later declaration can replace a trade-proven start with the declaration date.

Accepted direction

• Preserve the existing cycle id on ordinary re-declaration rather than minting an alias.
• Build the adoption input from the derived recorded book, not only the prior snapshot row's user stamp.
• Keep one privileged engine-side adoption primitive in book_refresh.py; the review lane consumes that result rather than adding a second provenance writer in snapshot_adapter.
• A sold and re-entered position uses the derived rebuy start and therefore gets a new cycle naturally.
• Reserve relink aliases for a genuine later-history correction such as [design] A snapshot-inferred cycle start is now final — the relink that let a later CSV correct it rode on the completeness flag #549 removed #563, where the known start actually changes.

This is the smallest fix because stable identity makes all existing thesis/rationale readers work without question-layer changes.

Required revision: recorded_book must not erase epistemic quality

Do not use a single since_basis = "recorded_book" as the only description of every carried start.

That value describes how the date was transported into the new declaration, not why the date is believed. It would collapse at least two materially different facts:

• an exact start supported by a recorded trade event;
• a lower-bound/bookkeeping start inferred from a holdings declaration date.

Those dates must not later be rendered or judged with the same precision merely because both survived through the recorded book.

The implementation must preserve the original epistemic basis, either by:

1. expanding the engine-owned basis vocabulary (for example trade_event | snapshot_anchor | user_estimate | unknown) and carrying it unchanged; or
2. keeping an explicit source/precision field beside a transport marker.

Whichever shape is chosen, these truths must remain mechanically distinguishable after repeated adoption and projection repair:

• trade-proven date;
• snapshot-inferred date/lower bound;
• user-estimated date;
• unknown date.

Do not make renderers infer precision later from a generic recorded_book stamp or from the latest anchor's origin, because after adoption that origin describes the new snapshot writer, not the original evidence for the start.

Acceptance additions

• A trade-derived start survives a later declaration and remains labelled trade-derived/exact.
• A first-snapshot start survives later declarations but remains labelled snapshot-inferred, not trade-proven.
• A user estimate retains its estimate semantics and does not become generic recorded-book truth.
• Sold/rebought receives the rebuy start and no prior rationale/thesis.
• Both refresh and review adoption call the same primitive.
• Repeated adoption is a fixpoint; replay and repair-projections preserve identity and provenance quality.

The core feedback is therefore reasonable and should be implemented, but the proposed one-value provenance model should not land unchanged.