Why: The RDM plan's 2026-10-07 snapshot (downstream at zero, N1 in
flight, O1/O3/O7 blocked) was contradicted by the RDM repo's 103 merged
PRs; the planning index registered this as an open reconciliation item
and named it the preferred follow-up to the stage-record task.
Evidence: isolated clone replay at RDM 4feb2f0 (pins=v0.1.0) - make
test exit 0, -ms1 PASS (same-source gold caveat recorded), ms0
acceptance PASS=9/SKIP=0 on a disposable postgres container, five
upload probes, and entrance probes (chat 400 vs commands 200); card/
PR snapshot JSON; all receipts SELF (RDM has no CI), stored under
docs/records/2026-10-08-rdm-status-*.json. The private minutes probe
receipt stays local by decision; only hashes and metrics are recorded.
Impact: adds plan SS2.3 (row-by-row re-verdict, MS1 seven-clause audit,
six registered gaps), marks SS2 as a historical snapshot, updates the
index milestone table and closes the RDM-snapshot open item, registers
the dual-main-record ruling and the missing-CI gap.
Refs: Dev task feature/rdm-status-review; Documents index next-step
(2026-10-08).
Why: The planning index listed the stage-record reconciliation as the
preferred next task: N1 WP6b/6c transfers, the Q1 platform-task vs
squad-run boundary, I1 reserved command consumption, and the I2 card's
dangling reference all feed N2/Q3 and RDM dependency judgments.
Evidence: Dev merges #230/#231/#234/#235/#237/#240/#242 verified in
main via git log --merges on 2026-10-08; stage claims are SELF-level
card statements, explicitly not replayed; intent command.go:18-25/78-84
checked for the Cancel/Handoff ruling.
Impact: Adds a status-backfill section (SS7) to the N1/Q1/I1 plan with
per-item done/transferred/todo ownership, an I2 status note in the
stack completion plan (the sole I2 main record), and INDEX navigation
updates; registers the truncated Q2/Q3 archive lines as a new open
item.
Refs: Dev task feature/agent-stack-stage-records; planning index
"next-step" recommendation (2026-10-08).
Why: documents main gained two plans after the index snapshot, and Dev has since merged N2, N3, Q2, and Q3.
Evidence: 21 markdown proposals are present at HEAD; merge SHAs were read from Dev origin/main git log --merges.
Impact: navigation only; proposal bodies and acceptance claims are unchanged.
Refs: Documents #43#44; Dev #244#247#248#249#250#251#253
Why: the index branch was cut before N3 and Q2/Q3 plans landed on main.
Evidence: merge-tree reported no content conflicts against origin/main 16795ed598.
Impact: bring those two proposal files into the index branch without rewriting history.
Refs: documents main
Why: N1-N3/Q1/I1-I2 are closed; per the completion doc dependency
order Q2 then Q3 are next. Both need plans grounded in current code:
squad has no topology abstraction (two modes, dormant Cond
combinators, dead FactItem.Verified), RespondDecision has no actor
attribution (the mailbox acceptance attack surface), WorkflowDef
execution compresses steps into SpawnSubagent, and adapters/a2a does
not exist.
Evidence: three-area survey with file:line citations at the pinned
baselines (agent-squad c462bc4, backend 6e02a1f); the review
equivalence baseline is quoted from backend runReview with its test
anchors; the P4 ruling is quoted verbatim from agent-harness.md.
Impact: documentation only; Q2 implementation starts after merge,
Q3 after Q2 closes.
Refs: 2026-10-02-agent-stack-completion.md Q2/Q3 sections
Why: N2 is closed; per the completion doc's dependency order N3 is
next and needs a plan grounded in current code (the crash window
between persist and intent commit is unprotected, the product
conversation path has zero durability, span names/attributes do not
follow the GenAI convention, the memory port does not exist).
Evidence: five-area survey with file:line citations at the pinned
baselines (agent-native 74aa60b, backend 7980a8a, core 0b5c774);
audit N1/N21 verified fixed, N6/N20 verified still open.
Impact: documentation only; work starts after this plan merges.
Refs: 2026-10-02-agent-stack-completion.md N3 section
Why: expose existing milestone records and distinguish source observations from combination tests.
Evidence: linked records exist at the fixed source version; proposal blobs and the observation receipt remain unchanged.
Impact: index wording and navigation only; no plan or acceptance decision changes.
Refs: docs/proposals/INDEX.md
Why: author and task-account names do not establish ownership of a plan.
Evidence: independent review found four missing owner fields in the adopted set and N2 also has none; fourteen source headers explicitly name weichen.
Impact: correct the index attribution and clarify the local N2 document adoption boundary; source proposals remain unchanged.
Refs: planning-index review P2; docs/proposals/INDEX.md
Why: make existing directions, milestones and tasks discoverable without treating document claims as acceptance.
Evidence: fixed file blobs, 55 PR API records and Git ancestry are preserved as SELF observations; document links and all 19 proposals are checked.
Impact: navigation and evidence only; original plans, approval scope and business code are unchanged.
Refs: Dev feature/planning-index; docs/proposals/INDEX.md
Why: N1/Q1/I1/I2 are closed; per the completion doc's dependency order
N2 is next and needs a plan grounded in current code (the audit's N4 is
still open; the product-side ctxasm trim is the real gap for acceptance
clause 2; MCP 2026-07-28 features are absent).
Evidence: six-area survey with file:line citations at the pinned baselines
(agent-native ead690b, backend 68addfd); audit items N2/N3/N18/N19/N22
verified fixed against current code, N4 verified still open.
Impact: documentation only; work starts after this plan merges.
Refs: 2026-10-02-agent-stack-completion.md N2 section
Why: The further-objective docs are now the system's next big-phase
target; the plan pins the two-tree-one-net product on top of the
generic platform with two hard invariants - downstream-only domain
logic and always-degradable-to-generic-agent when the plugin is off.
Evidence: docs-only change; milestone mapping verified against
further-objective 10 (W1-W16), readiness claims verified against the
pinned worktrees (EXT-1 symbols in surface.txt, v0.1.0 tags, RDM repo
seed facts as recorded in vision doc 13).
Impact: Adds one proposal; no code changes.
Refs: docs/proposals/2026-10-07-agent-stack-n1q1i1-plans.md
Why: The completion proposal defines the N1/Q1/I1 phases but not their
work packages; D1 has landed, so the three phases are now unblocked and
need file-level plans grounded in the current pins.
Evidence: docs-only change; file:line claims verified against the pinned
worktrees (native 3a110a7, squad 5a57636, intent 65aaebc, backend
e7fb276).
Impact: Adds one proposal and one link line; no code changes.
Refs: docs/proposals/2026-10-02-agent-stack-completion.md
Why: downstream parsers are unreachable through the Host handle and the base lacks xlsx/pptx parsers; MS1 needs both. The snapshot also missed interface methods, so adding one was undetectable.
Evidence: request follows compat-policy sect.6 four elements; behavior contract and limits in the proposal body (documents has no CI; verified via git diff --check recorded on the Dev task card).
Impact: docs only; compat-policy sect.3 gains one sentence, usage.md format list gains xlsx/pptx.
Refs: docs/proposals/2026-10-06-ext-5-host-parse-document.md
Why: AGENTS.md requires PROJECT.md but the referenced project facts and verification entry did not exist.
Evidence: SELF git diff --check and checked the README reference and Dev verification targets.
Impact: adds documentation-specific validation and evidence limits; no runtime change.
Refs: Agent-System-Dev feature/governance-reliability audit remediation
Why: The comparison has to say what was borrowed, what was refused, and which product behaviors changed, without copying upstream text.
Evidence: The record lists the verified security gaps and the features implemented in this task. Proposal section 2.5 links to it.
Impact: Deferred and rejected items stay deferred and rejected. Adopted context and secret behavior is no longer described as a later batch.
Refs: feature/sillytavern-review
Why: The October 3 durable note described Pico5 before packages 1-23 existed, and the stack proposal had no place for the v1.0.1 and ZCode v3.14.3 findings.
Evidence: The new record, the correction at the top of the durable note, and proposal section 2.4 link to each other. No code changes.
Impact: Documents only. Later batches can cite the adopt, hold, and reject rows.
Refs: Dev feature/pi-zcode-second-pass
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: The review record still said the proposal was unmerged, but Documents PR #34 is on main and this branch is cut from that commit.
Evidence: origin/main is 76044b5, the merge of feature/agent-stack-blueprint.
Impact: One sentence in the review record. The proposal text is unchanged.
Refs: Dev feature/pi-durable-borrow
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: Pico5's package is a contract sketch, but its commit and recovery rules match four verified gaps in how runs survive a hard kill.
Evidence: Reviewed earendil-works/pi @ c7cdb460a, packages/durable and docs/pico-v5.md, against the skeleton section 4.2 and the current backend store, run manager, and SSE handler.
Impact: Documents only. The record rejects taking the package as a dependency and lists what the matching backend task changes.
Refs: Dev feature/pi-durable-borrow
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: The three libraries cannot be reused or recovered independently, and the tested dependency combination is not the one the product builds.
Evidence: Read-only audit at native c6d867c, squad 590fd86, intent 1dbbe81, recorded with file references in docs/records/2026-10-02-agent-stack-audit.md.
Impact: Documents only. No library code or gitlinks change in this commit. Later stages stay separate tasks.
Refs: Dev feature/agent-stack-blueprint
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: The harness proposal still said the script decision was deferred, after the implementation chose both declarative workflows and two dynamic forms.
Evidence: The P4 section now states routing order, copy-on-start, step and retry caps, and the script switch.
Impact: Documentation only.
Refs: feature/agent-harness-p4
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: Tool-call history is flattened into assistant text, so the model imitates calls and invents artifact ids. The fix belongs to a shared harness, not another prompt tweak.
Evidence: Proposal 2026-10-01-agent-harness.md records the 2026-10-01 session evidence, the ZCode and Claude Code patterns, and the P0-P4 acceptance.
Impact: Documents only. P0 code lands in the backend on the same branch name. P1-P4 are not implemented here.
Refs: feature/agent-harness-p0
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: The base must stay unmodified by downstream products, so the roadmap, compatibility window, and plugin contract need a written proposal before further forks.
Evidence: Three proposals under docs/proposals and a short pointer in the plugin development guide.
Impact: Tag commands in the compat proposal are not executed.
Refs: Agent-System-Dev feature/base-extension-roadmap
Why: The base must stay unmodified by downstream products, so the roadmap, compatibility window, and plugin contract need a written proposal before further forks.
Evidence: Three proposals under docs/proposals and a short pointer in the plugin development guide.
Impact: Downstream work follows extension-point requests and a published base version. Tag commands in the compat proposal are not executed.
Refs: .task/feature-base-extension-roadmap.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: user approved the proposal 2026-09-30 and directed implementation.
Evidence: approval recorded in status line and D49 note.
Impact: docs-only; unlocks CF-S task start.
Why: parallel conversations in one project cannot see each other's
transcripts, which already caused duplicate delivery of the same
requirement (records/2026-09-30-lesson-parallel-session-duplication.md);
artifacts/knowledge are already project-shared, so transcripts are the
only missing channel.
Evidence: permission formula and gate matrix designed fail-closed
(project switch default off; per-conversation outbound/inbound flags
default open/shared); tool design lands the "conversation history
search" builtin planned in skeleton design 4.8.
Impact: documents only; implementation follows in core/backend/frontend
under Dev task feature/cross-session-reading.
Refs: proposals/2026-09-29-system-skeleton-design-and-plan.md 4.8/4.9;
records/2026-09-30-lesson-parallel-session-duplication.md.
Why: proposal must record the 2026-09-30 decision (avatars, cards,
settings as base capabilities plugins reuse) and where it landed.
Evidence: feature/ui-capability-platform across core (avatar
vocabulary), ui (shared components + full vocabulary renderers),
frontend (consumption); 35+ tests and headless walk green.
Impact: status line only.
Why: the user replaced the stage-2 email self-registration sketch with
admin-issued accounts (2026-09-30): no self registration, admin sets
initial passwords, first login after creation or reset forces a change.
Evidence: R2 landed on feature/auth-admin-accounts (migration v10,
auth/session APIs, CLI user subcommands, login page + forced change
gate + admin user management); store/e2e tests and a full headless
journey on the real binary are green (see that task's PR).
Impact: proposal status line only; section 5.1 sketch superseded.
Why: the backend now registers tavily_search/web_search via
Agent-Native's TavilyProvider, so the guide's not-ported reason no
longer holds.
Evidence: backend PR records the registration and runtime checks.
Impact: table row updated, library count 44 -> 46.
Refs: feature/tavily-search-tool task card.
Why: the user picked option A (task-centric) after reviewing the demos;
the proposal status must reflect the decision and where R1 landed.
Evidence: R1 delivered on feature/task-sidebar-r1 across core/backend/
frontend (contract flags, migration v8, task list APIs, TaskSidebar);
headless walk and test suites green there.
Impact: status line only; no design content change.
Why: deciding what enters the library from an external prompt catalog
needs a stated rule (carrier mechanism or future slot) and an auditable
per-item disposition, otherwise coverage drifts by reviewer taste.
Evidence: table maps every Claude Code catalog entry to a library module
or an explicit not-ported reason.
Impact: guide gains section 9; no code change.
Refs: feature/prompt-catalog-coverage task card.
Why: the prompt system's design rationale (layering, the eight module
patterns, trigger semantics, override chain) needs to live with the
docs so future prompt work follows it instead of re-deriving it.
Evidence: guide content distilled from the implemented library and the
Claude prompt catalog analysis recorded in the task card.
Impact: new docs/guides/prompt-library-design.md; no code change.
Refs: feature/prompt-library task card.
Why: current UI scatters creation entries (project + at sidebar top-left,
new session at bottom-left), has no user/tenant surfaces, and the project
tree forces per-project navigation; the system targets multi-user
multi-tenant operation.
Evidence:
- Studied zai-org/ZCode desktop layout (WorkspaceShellLayout, WorkspaceSidebar,
DESIGN.md) and mapped transferable patterns (single New-Task entry,
organize-by views, sidebar account footer) with repo file citations.
- Three layout proposals (task-centric / activity rail / project portal) with
comparison table and recommendation A; auth stage-2 design (orgs,
memberships, server sessions) with SSE cookie upgrade removing ?key=.
- Five static demos (index + A/B/C + auth) verified headless: DOM layout
assertions (column widths, view switching, screen switching), clipping and
contrast QA clean, zero console errors, light/dark themes render.
Impact: documents only; no code change. Demos double as the R4 design-token
target palette. Implementation proceeds only after direction is approved.
Refs: docs/proposals/2026-09-30-ui-inbox-command-workspace.md (D25-D33),
docs/proposals/2026-09-30-dual-tier-storage-and-multitenancy.md (D17-D24)
Why: T2-T4 changed the interaction foundation (pure-inbox rail, four-entrance command bus, overlay workspaces) and the guide still described the classic tabs; T5 acceptance also requires the verification record with the zero-page walkthrough.
Evidence: zero-page walkthrough 12/12 PASS on a fresh real binary (fresh data dir: empty instance -> project/conversation -> slash commands -> #upload card lifecycle -> card action receipts -> tidy -> HITL block+resolve -> button-entrance dispatch -> plugin workspace declaration -> artifacts -> four-entrance audit); StatusLamp shape+color dual encoding asserted by ui suite; combo make test at pinned heads.
Impact: usage guide sections 4.2-4.7/5/6.2/7 rewritten; new T5 record; no code change.
Refs: docs/proposals/2026-09-30-ui-inbox-command-workspace.md T5; task card feature/polish-r1
Why: T4 acceptance requires a verification record in this repo before the Dev combo pin.
Evidence: backend full sweep green with TestWorkspacesOverlay; ui 23/23 (OverlayHost semantics); frontend tsc+vitest+build; example plugin workspace/command assets JSON-validated; combo make test at pinned heads.
Impact: docs/records only.
Refs: docs/proposals/2026-09-30-ui-inbox-command-workspace.md T4; task card feature/workspaces-r1
Why: T3 acceptance requires a verification record in this repo before the Dev combo pin.
Evidence: backend 15 pkgs ok incl. new cmdbus suite and danger-confirm e2e (dispatch -> confirm card -> action -> committed -> audit query ordered); ui 18/18; frontend 9/9; combo make test at pinned heads.
Impact: docs/records only.
Refs: docs/proposals/2026-09-30-ui-inbox-command-workspace.md T3; task card feature/command-bus-r1
Why: Delivery gate requires a verification record with per-case PASS evidence
for the T1 contract task before requesting review.
Evidence: record covers core/agent-command/frontend/ui suites, combo test and
the additive-compatibility check; contract change list enumerated.
Impact: Documentation only.
Refs: Dev task feature/core-cards-commands-r1
Why: Record the approved design for the interaction foundation phase — inbox/
command-bus/workspace mechanisms sink into the base system, domain views stay
plugin territory (target-system strategy), decisions D25-D33.
Evidence: proposal covers background, five UI principles, dialogue-completeness
P0 constraint, module/repo split (Agent-System-UI, Agent-Command), contract
sketch, task sequence T0-T5 and acceptance criteria.
Impact: Becomes the design baseline for T0-T5 tasks across five repos.
Refs: Agent-System-Dev feature/ui-foundation-r0
weichen
