Tianyi Cui f2c0021941 docs(notes): aggressive archive sweep of low-value decision records

Archive 21 implemented triplets whose shipped decisions are complete and
whose bodies no longer guide future work (one-off UI chrome, generator
applications whose scripts are self-explanatory, superseded implementation
detail, process history owned by current contracts/skills). Delete 4
rejected triplets whose premises are obsolete: the DeepReadonly proposal
(dev-invariants note now carries the alternative inline), the collapse
tool-owned presentation proposal (superseded by the shipped render-intent
union), retire-mid-turn-steering (steering is now load-bearing across
plan-mode/apiproxy/TUI), and single-session-ACP (automation-only ACP
resolved the question; multi-session isolation is pinned by tests).

Repair every inbound link: retarget intentional historical citations to
archived paths, replace decision-current citations with the surviving
authority, and fix the stale example-execute-over-tsx pointer in
pnpm-workspace.yaml. Re-record pairing sidecars and seal the archive
manifest (append-only; existing seals unchanged).

2026-07-28 00:00:51 +08:00

1.7 KiB

Raw Blame History

Agent Note: Tool schemas are part of the system-prompt assembly

Status: implemented Archived: 2026-07-27

English | 中文

Problem

On the wire, tool schemas travel in a dedicated tools field of the model request, not in prompt text. Architecturally, though, "what the model is told it can do" is one coherent concern: prompt sections and the tool list are assembled from the same plugin contributions and consumed at the same moment.

Decision

PromptAssembly { sections, tools }: the system-prompt service collects ordered text sections AND tool schemas (the tool registry auto-contributes a provider). The loop consumes one assembly per step; adapters map sections to the provider's system slot and tools to the wire tools field. The system-prompt/assemble waterfall is therefore a single interception point for everything the model is told up front — tool filtering (ToolSearch / progressive disclosure) is an assembly rewrite, same as prompt edits.

Alternatives considered

The loop queries the tool registry separately from the prompt service — splits one coherent concern across two seams, and every interception that wants to shape "what the model is told" (tool filtering, plan mode) would need two listeners on two surfaces instead of one assembly rewrite.

Consequences

One waterfall governs the model's standing context; plugins like plan mode can swap prompt text and visible tools in one listener.
The assembly interface is merge-extensible for future slots (no untyped extras bag — extension is declaration merging).
Slight conceptual surprise (schemas in a "prompt" service) is documented here and in the package README.

1.7 KiB Raw Blame History