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: D1-D5 were settled by the user (deps in, full-fidelity pptx, OG
card plus optional embed, dual placement); the proposal status must
reflect that before implementation starts.
Evidence: decision section rewritten with the settled choices and the
accepted trade-off on D2 (fall back to outline level with evidence only
if no Vite-compatible renderer builds).
Impact: documentation only.
Refs: task feature/file-preview-caps.
Why: agents rediscovered Gitea hosts and credential locations from
scratch each session, and the retired git-panel host kept failing with
TLS broken-pipe errors before the right host was recalled.
Evidence: curl git-home...:30319/api/v1/version with token from
~/.secrets/gitea -> {"version":"1.27.3"}; ssh -p 31411 git@git-ssh...
(BatchMode) -> "Hi there, weichen!" with key ~/.ssh/home_gitea (ED25519,
SHA256:GYXaOXIMeloQ1fKSfdJ/ndgPQzs/Ix7Hk62ekfkfQ20). Same section already
merged in Agent-System-Dev (PR #73).
Impact: AGENTS.md only; records hosts and credential locations, no
secret values (baseline hard boundary 2).
Refs: Agent-System-Dev PR #73
Why: the user asked for a reviewable plan covering (a) previews for
office/image/markdown/code files and web links, docked in the right rail
or the system overlay, (b) keeping artifact deletion as a capability with
no UI entry, and (c) implementing fs tools without enabling them.
Evidence: the proposal assesses each idea against current architecture,
defines the FilePreview capability component with a format matrix and
lazy-loaded office parsers, the SSRF-guarded url-preview endpoint, the
gated sandboxed fs tool family, four delivery phases with acceptance
criteria, and decision points D1-D5 for the user.
Impact: documentation only; implementation follows in a separate task
after D1-D5 are settled.
Refs: task feature/file-preview-proposal; extends 2026-09-30
ui-redesign-and-auth.md section 9.
Why: the delivery log for the 2026-09-30 afternoon fixes (part-order
fidelity, download channel, artifact file management, settings cascade)
belongs with the redesign proposal it extends, including the two durable
conventions it produced.
Evidence: adds section 9 with root causes, the render-order-equals-
storage-order rule, the compound-selector lesson for @ui shells on host
generic classes, and the full verification record (vitest/go suites plus
the 12/12 headless run).
Impact: future UI work inherits both conventions without rediscovering
the failure modes.
Refs: task feature/chat-order-artifact-files.
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
weichenandCursor