@vostride/agent-qa-agent 0.2.3 → 0.2.4

package/dist/index.d.ts

@@ -1,13 +1,7 @@
-import { ScopeKey, AuthoringBrief, Delta, CanaryOutcome, RecordId, GateReceipt, PromotionOutcome, GateReceiptRecordOutcome, Action, ActionResult, Patch, PatchId, Job, JobStatus, JobId, JobKind, JobEnqueueRequest, JobConclusionKind, DraftReceipt, TestEditPatchSet, RunsStartInput, RunStartAcknowledgement, CompletedRunHandoff, AuthoringVerifyDraftInput, TestFileWrite, QuarantineEntryState, SuiteStabilityAssessment, AuthoringFunnelWindow, AuthoringFunnel, ConfigChange, ConfigWriteRefusal, ConfigWriteIssue, ConfigPathSegment, CatalogRow, ExplainCitation, QuarantineLadderState, Verdict, VerdictSentenceParts, ChainedJobRequest, JobHandlerOutcome, RunAnalysisArtifact, ClauseReceiptStatus, AgentAskInput, AgentAskResult, MaskedResolvedConfig, RunId, StepEvidence, RecordedTargets, KnowledgeGatesListResult, KnowledgeCandidateInjectionResult, KnowledgeBundleSummary, KnowledgeRecordsInspectInput, InspectRecordView, KnowledgeRecordsDiffInput, RecordChange, KnowledgeRecordShowInput, KnowledgeRecordShowResult, EntityResolution, EntityDescriptor, LiveUrlSigner, LiveStreamDeclaration, KnowledgeAcceptInput, KnowledgeRejectInput, KnowledgeForgetInput, KnowledgeChangeOutput, PostProcessingStageDetail, CurationSnapshot, RunNotification, RunDetailRows, EvidenceBlobLookup, EvidenceBlobPresence, QuarantineOperationsPort, FeedbackPort, FeedbackReadsPort, MaskFn, RiskActionDescriptor, FunctionCaller, LiveUrlClaims, LiveViewSubjectRef, LiveUrlVerdict, AuthoringDedupContinuation, VerdictSource, RunEvidenceRef, DraftRef, WrittenTestReceipt, AuthoringDraftWriteOutput, FanOutReport, FanOutBound, ChatSessionEvent, ChatAbortedEvent, RefusedChatSessionLine, ChatTurnStatus, ClauseReceipt, ChatCompactionEvent, SessionLogPort, ScenarioClass, ChatScenario, ScenarioLane, ScenarioExpectationKind, AnalysisGetOutput, MisdirectionRootPosture, ExecutionContext, RunNotificationVerdictSummary, GateVerdict } from '@vostride/agent-qa-schema';
+import { ScopeKey, AuthoringBrief, Delta, CanaryOutcome, RecordId, GateReceipt, PromotionOutcome, GateReceiptRecordOutcome, Patch, PatchId, Job, JobStatus, JobId, JobKind, JobEnqueueRequest, JobConclusionKind, DraftReceipt, TestEditPatchSet, RunsStartInput, RunStartAcknowledgement, CompletedRunHandoff, AuthoringVerifyDraftInput, TestFileWrite, QuarantineEntryState, SuiteStabilityAssessment, AuthoringFunnelWindow, AuthoringFunnel, ConfigChange, ConfigWriteRefusal, ConfigWriteIssue, ConfigPathSegment, CatalogRow, ExplainCitation, QuarantineLadderState, Verdict, VerdictSentenceParts, ChainedJobRequest, JobHandlerOutcome, RunAnalysisArtifact, ClauseReceiptStatus, AgentAskInput, AgentAskResult, MaskedResolvedConfig, RunId, StepEvidence, RecordedTargets, KnowledgeGatesListResult, KnowledgeBundleSummary, KnowledgeRecordsInspectInput, InspectRecordView, KnowledgeRecordsDiffInput, RecordChange, KnowledgeRecordShowInput, KnowledgeRecordShowResult, EntityResolution, EntityDescriptor, LiveUrlSigner, LiveStreamDeclaration, KnowledgeAcceptInput, KnowledgeRejectInput, KnowledgeForgetInput, KnowledgeChangeOutput, PostProcessingStageDetail, CurationSnapshot, RunNotification, RunDetailRows, EvidenceBlobLookup, EvidenceBlobPresence, QuarantineOperationsPort, FeedbackPort, FeedbackReadsPort, MaskFn, RiskActionDescriptor, FunctionCaller, LiveUrlClaims, LiveViewSubjectRef, LiveUrlVerdict, AuthoringDedupContinuation, VerdictSource, RunEvidenceRef, DraftRef, WrittenTestReceipt, AuthoringDraftWriteOutput, FanOutReport, FanOutBound, ChatSessionEvent, ChatAbortedEvent, RefusedChatSessionLine, ChatTurnStatus, ClauseReceipt, ChatCompactionEvent, SessionLogPort, ScenarioClass, ChatScenario, ScenarioLane, ScenarioExpectationKind, AnalysisGetOutput } from '@vostride/agent-qa-schema';
 import { EventLogPort } from '@vostride/agent-qa-runner';
 import { ModelMessage, LanguageModel, ToolSet } from 'ai';
 
-/**
- * D-13 authoring-read port: the M4 QA agent's screenless seam, minted beside KnowledgePort and
- * test-proven in M2 with no CLI surface (382's verb family or M4 adds one). Read-only law: this
- * port must survive 382's no-write-symbol module-boundary proof — no Delta/commit/promote symbol
- * may ever join it. The runner's six-method KnowledgeHintReader hot-path contract is untouched.
- */
 interface AuthoringReadPort {
     getAuthoringBrief(intent: string, scope: ScopeKey): Promise<AuthoringBrief>;
 }
@@ -20,57 +14,6 @@ interface KnowledgePort {
     recordGateReceipt(receipt: GateReceipt): Promise<GateReceiptRecordOutcome>;
 }
 
-/**
- * 2026-09-06, 416 D-10: replayGateAvailable is true iff a host composition bound this port.
- * Phase 416 binds nothing; Phase 417 binds runReplayGate.
- *
- * 2026-09-11, 422 D-14 — THE ACKNOWLEDGEMENT CONTRACT, stated on the port rather than in the
- * adapter that happens to implement it today.
- *
- * A resolved `runReplayGate` means the returned receipt is DURABLE: the writer capability
- * acknowledged persisting it. It does not mean "a receipt was generated". The distinction is
- * the whole point — a Gate-1 run costs replay work no later run can recover, and a caller that
- * read a generated-but-unwritten receipt as a screening result would report a candidate as
- * screened whose evidence nothing can find afterwards, then refuse to screen it again because
- * its own memory says it already did.
- *
- * So the contract is one-sided on purpose: persistence refusal, a stale writer fence, a lease
- * held by somebody else and a dry run are all REFUSALS, surfaced through this port's existing
- * error path as {@link Gate1ReceiptNotPersistedError}. There is no acknowledgement member on
- * the returned receipt, because a receipt that reached this caller at all is already the
- * acknowledged one and a flag saying so would be a second answer to the same question.
- */
-interface ReplayGatePort {
-    runReplayGate(candidateId: RecordId): Promise<GateReceipt>;
-}
-/**
- * The Gate-1 call produced a receipt that the writer did not acknowledge persisting (422 D-14).
- *
- * PROVIDER-NEUTRAL, and it lives here rather than in the CLI adapter for the reason every other
- * port refusal does: the caller that has to tell "screened" from "spent but unrecorded" is the
- * job handler, two packages away from whichever host bound the port, and an adapter-private
- * class would make that distinction reachable only by matching on message text.
- *
- * `recorded` carries the writer's own word for what happened — `dry-run`, `lease-held`,
- * `lease-refused`, or whatever a future writer adds — because a caller deciding whether to
- * retry wants to know WHICH refusal it met, and a boolean would flatten a transient lease
- * contention into the same fact as a deliberate dry run.
- *
- * What this error does NOT carry is the receipt. Handing back the bytes of a receipt nothing
- * stored is exactly the affordance that lets a caller record a screening result the store will
- * never agree with.
- */
-declare class Gate1ReceiptNotPersistedError extends Error {
-    readonly candidateId: string;
-    readonly recorded: string;
-    readonly name = "Gate1ReceiptNotPersistedError";
-    constructor(candidateId: string, recorded: string);
-}
-
-interface ToolsPort {
-    execute(action: Action): Promise<ActionResult>;
-}
-
 interface PersistencePort {
     savePatch(patch: Patch): Promise<void>;
     getPatch(id: PatchId): Promise<Patch | undefined>;
@@ -80,12 +23,6 @@ interface ClockPort {
     now(): string;
 }
 
-/**
- * The authority token a drain-side verb must present.
- *
- * Deliberately a plain epoch record, not an opaque handle: 386 binds the v51 writer lease
- * as its source, and that lease's authority already IS an integer epoch on disk.
- */
 interface JobStoreFence {
     readonly epoch: number;
 }
@@ -103,73 +40,22 @@ interface JobCheckpointRecord {
     readonly recordedAt: string;
     readonly value: unknown;
 }
-/**
- * Refusal at the mutation boundary, mirroring v51's `WriterAuthorityLostError` shape: a
- * named class carrying both the epoch the caller held and the epoch the store observed, so
- * a log line says which writer was behind and by how much.
- */
 declare class StaleJobStoreEpochError extends Error {
     readonly heldEpoch: number;
     readonly observedEpoch: number;
     readonly name = "StaleJobStoreEpochError";
     constructor(heldEpoch: number, observedEpoch: number);
 }
-/**
- * One job row to insert: a caller's `JobEnqueueRequest` plus what the engine resolved for it.
- *
- * 385 plan 02 split this from the request DTO rather than duplicating it. The request is the
- * three facts a CALLER knows; the two fields added here are derived at the engine boundary
- * and belong to nobody else. The id is derived from `(kind, idempotencyKey)` through an
- * injected id source, so the same logical job carries the same id in every process and in
- * every replay (D-03 corollary) — a store that minted its own would break that, and a caller
- * that supplied its own could break it twice. Timestamps are absent on purpose: the store
- * stamps them from ITS injected clock, so no SQL-side default can leak host time into a dump.
- *
- * There is no separate "chained enqueue" type. A successor differs from a root job in who
- * asked for it, not in what it is, and the difference that does matter — a successor is
- * inserted inside its predecessor's transaction — is expressed by the verb it arrives at.
- */
 interface JobInsert extends JobEnqueueRequest {
     readonly id: JobId;
     readonly summary: string;
 }
-/**
- * Refusal when an operator tries to requeue a row this build cannot read (422 D-16).
- *
- * A requeue is the one operator verb that DESTROYS history — it resets the attempt count, deletes
- * every checkpoint row and file the last attempt recorded, and disowns the run's chain-terminal
- * notification. For an ordinary terminal row that is the whole point: the row goes back so a fixed
- * handler can run it again. For a quarantined row there is no handler to run it again — no kind
- * registry contains its kind — so the reset would spend the remedy and buy nothing: the very next
- * claim would quarantine the row a second time, and the spent attempt and the fixed reason that
- * recorded WHY it was quarantined would be gone.
- *
- * Raised INSIDE the requeue's transaction and before any of those three media is touched, so a
- * refused requeue leaves the store byte-identical.
- *
- * THE MESSAGE DOES NOT NAME THE KIND, and that is the same rule
- * `QUARANTINED_UNREADABLE_KIND_REASON` states for `last_failure_reason`: the unreadable kind is
- * a string an EARLIER build -- or anything with write access to that database -- put in a
- * column, and this message is rendered on operator terminals and copied into logs.
- * Interpolating it here took the one field of the row this build refuses to trust and pasted it
- * into the one place an operator is most likely to read without thinking. The value stays on
- * `unreadableKind`, where a caller has to ask for it and knows what it is when they do --
- * exactly where the `kind` column keeps it.
- */
 declare class QuarantinedJobRequeueError extends Error {
     readonly jobId: string;
     readonly unreadableKind: string;
     readonly name = "QuarantinedJobRequeueError";
     constructor(jobId: string, unreadableKind: string);
 }
-/**
- * The result of an enqueue.
- *
- * `deduped` reports that the unique index already held this `(kind, idempotencyKey)` pair
- * and `job` is the pre-existing row. A duplicate enqueue is a SUCCESS, never an error —
- * that is what makes "run the tail twice, get one job" a store guarantee rather than a
- * convention every caller has to remember (D-08).
- */
 interface JobEnqueueOutcome {
     readonly job: Job;
     readonly deduped: boolean;
@@ -189,17 +75,6 @@ type JobClaimOutcome = {
     readonly job: Job;
     readonly payload: unknown;
 };
-/**
- * What a claim may be told is not its to take (Phase 388-09, G-388-2 substrate).
- *
- * The exclusion is an OWNERSHIP declaration: a host names the kinds it may not claim, fixed
- * when its queue is composed. A kind on this list must be left exactly as the claim found it
- * — never claimed and released — because per D-18 the attempt is spent AT the claim, and
- * (388-09 Task 1, M-2) a released row is re-offered ahead of every younger row, so a
- * claim-then-release "refusal" either burns the row's bound or starves every other kind
- * behind it for as long as the row exists. The only refusal that writes no receipt and
- * costs nothing is one where the excluded row is never offered at all.
- */
 interface ClaimNextOptions {
     readonly excludeKinds?: readonly JobKind[];
 }
@@ -212,16 +87,6 @@ interface JobFailAndChainOutcome {
     readonly job: Job;
     readonly chained: readonly JobEnqueueOutcome[];
 }
-/**
- * How a failed attempt should be disposed of. Behaviour lands with the retry plan.
- *
- * This is NOT a second spelling of the handler's `JobHandlerOutcome`, and the two are kept
- * apart deliberately (385 plan 02). The handler REPORTS whether the thing that went wrong
- * could go right next time; the engine DECIDES what to record, and only the engine knows how
- * many attempts remain. A retryable report on the last permitted attempt becomes a permanent
- * disposition here — which is exactly the bound D-18 puts on retries, and it would have
- * nowhere to live if the report and the decision were one type.
- */
 type JobFailureDisposition = {
     readonly kind: 'retry';
     readonly reason: string;
@@ -236,17 +101,6 @@ type JobCheckpointReadOutcome = {
     readonly found: true;
     readonly payload: unknown;
 };
-/**
- * What asking to cancel a job actually did (D-19).
- *
- * Three outcomes, because cancellation genuinely has three cases and collapsing any two of
- * them loses a guarantee. A job nobody is running stops at once — there is nothing to be
- * cooperative about. A job in flight only records the REQUEST: terminating its row out from
- * under a running handler would abandon a half-finished step and leave whatever it was part
- * way through with no owner, so the driver honours the request at its next checkpoint boundary
- * instead. A job that has already finished, failed or been cancelled reports what it is and
- * nothing moves — a cancel is not an eraser.
- */
 type JobCancelOutcome = {
     readonly outcome: 'cancelled';
 } | {
@@ -255,38 +109,6 @@ type JobCancelOutcome = {
     readonly outcome: 'already-terminal';
     readonly status: JobStatus;
 };
-/**
- * What returning a finished job to the queue actually did (413 D-04/D-06 gap closure).
- *
- * A requeue is an OPERATOR's explicit act under the fence, not a lifecycle transition any
- * handler can reach. It exists because Phase 413's pump composed without the post-run
- * capabilities, the kind registry selected the STAND-IN analyze-run handler, and nineteen
- * rows reached `done` with a checkpoint recorded and nothing authored — a completion the
- * queue has no vocabulary to disown.
- *
- * `requeued` returns the row to `queued` with its attempts reset AND everything its last
- * attempt recorded FORGOTTEN in all three durable media, because they are one remedy rather
- * than three tidy-ups. The checkpoint rows and the checkpoint files go because `readCheckpoint`
- * resolves the LATEST recorded value across attempts, so a reset that kept the stand-in's
- * `verdicts-authored` row would hand the real handler the stand-in's value on the next attempt
- * and it would report completion having written nothing — the very substitution the requeue
- * exists to undo, performed a second time by the recovery path. The chain-terminal notification
- * the attempt minted for the run this job's payload names goes for a stronger reason: the
- * store's insert dedupes on the run (`ON CONFLICT (run_id) DO NOTHING`), so a receipt that
- * survives a requeue can never be replaced by the re-run — it would keep publishing an outcome
- * for an attempt whose every other trace the same transaction just deleted.
- *
- * What the requeue does NOT touch is the row's identity: the id and the
- * `(kind, idempotencyKey)` pair survive, so the chain identity `chainJobIdsForRun` derives
- * from the run id still addresses this row and a re-chained successor dedupes onto the
- * existing slot instead of doubling it. Enqueueing a fresh job under a new key would have
- * been the easier remedy and the wrong one.
- *
- * `not-terminal` is a refusal, and it carries the status it found. A queued or claimed job
- * belongs to a drainer: requeueing one would reset the attempt count out from under a
- * handler that is running, which is the two-writers-under-one-fence tampering the fence
- * exists to exclude.
- */
 type JobRequeueOutcome = {
     readonly outcome: 'requeued';
 } | {
@@ -306,52 +128,13 @@ declare class JobCancellationNotRequestedError extends Error {
     readonly name = "JobCancellationNotRequestedError";
     constructor(jobId: JobId);
 }
-/**
- * What a chain-terminal transition asks the store to record, if it really is terminal
- * (Phase 388, D-09 / D-10 / D-12).
- *
- * The 385 D-05 split, applied to a new decision. POLICY is already resolved by the time this
- * record exists: the engine decided which run this job belongs to, which ids the chain could
- * have enqueued, and what the notification should say. What the STORE decides is the only
- * part that cannot be decided outside a transaction — whether every candidate that exists is
- * terminal at the instant of the write, and whether this run has been notified already.
- *
- * `payloadJson` arrives serialized rather than as a value, and that is deliberate: the record
- * crosses a storageNeutral port into a store whose column is text, and canonical
- * serialization is a shipped primitive. A store that serialized it would be a second place
- * the bytes are decided, and the two would differ on the first key-order question.
- *
- * The parameter is OPTIONAL on both terminal verbs and defaults absent, so every existing
- * caller — the store-contract suite, the kill matrix, every kind that is not a chain member —
- * compiles and behaves exactly as before. A record that arrives for a chain that turns out
- * NOT to be terminal is not an error: the store simply writes nothing.
- */
 interface ChainTerminalRecord {
-    /** The UNIQUE key one notification per run rests on. `runId` alone (D-10). */
     readonly dedupeKey: string;
-    /**
-     * Every job the chain COULD have enqueued, whether or not it did.
-     *
-     * Candidates rather than members, because a derived chain id is not a promise that a row
-     * exists. `chainJobIdsForRun` derives EVERY one of the chain's ids from the run id alone, up
-     * front, while the rows appear one at a time: each successor is enqueued only once its
-     * predecessor chains, and a deduped or halted chain leaves a derived id no row will ever
-     * carry. The store's rule is therefore stated over the candidates that EXIST — a successor
-     * that has not been written yet cannot be read as a finished one, so the terminal cannot fire
-     * a job early. The head is the one exception and is checked by name: a chain whose analyze-run
-     * row was never written is not a run's chain at all.
-     *
-     * 2026-09-01 (Phase 409): the chain narrowed to two ids.
-     * 2026-09-11 (Phase 422, D-13): three again, the third being the proposal stage the fold now
-     * chains to. The candidate/member distinction is what carries that widening for free — a
-     * chain halted at a permanently failed fold has no proposal row, and the rule reads it as the
-     * absence it is rather than as an unfinished stage that blocks the record forever.
-     */
     readonly candidateJobIds: readonly JobId[];
     /** Canonical JSON of the `RunNotification` this terminal would record. */
     readonly payloadJson: string;
 }
-/** One row of the deterministic logical dump (D-03). Column names, not the DTO shape. */
+/** One row of the deterministic logical dump. Column names, not the DTO shape. */
 interface JobStoreDumpRow {
     readonly id: string;
     readonly kind: string;
@@ -361,39 +144,11 @@ interface JobStoreDumpRow {
     readonly payload: unknown;
     readonly attempts: number;
     readonly claimed: boolean;
-    /**
-     * Someone has asked for this job to stop (D-19).
-     *
-     * Store-owned state, exactly like `claimed`, and for the same reason: `JobStatus` is a
-     * shipped kernel vocabulary whose C6 break added the two TERMINAL members the queue needed,
-     * and "a running job that has been asked to stop" is not a terminal state — it is a fact
-     * about what has been asked of a job that is still queued. Adding a status member for it
-     * would be a second contract break to describe something no observer of the row needs to
-     * treat as a lifecycle stage.
-     */
     readonly cancelRequested: boolean;
-    /**
-     * What this row CONCLUDED, when the store can say it from the row alone (422 D-16).
-     *
-     * Present today for exactly one conclusion, `unreadable_kind`: a row written under a kind this
-     * build has since retired, landed permanently at claim without ever being parsed. It belongs on
-     * the DIAGNOSTIC projection rather than on `Job` because that is the only projection such a row
-     * can travel through at all — `Job.kind` is the strict five-kind enum, so a quarantined row is
-     * precisely the row the typed DTO cannot carry. Naming the column-shaped facts here is what lets
-     * a listing describe it instead of throwing on it.
-     *
-     * ABSENT means "this row concluded nothing the store can name", which includes an ordinary
-     * `done` row and a retired-kind row still sitting queued. It is not a summary of the status.
-     */
     readonly conclusionKind?: JobConclusionKind;
     readonly createdAt: string;
     readonly updatedAt: string;
 }
-/**
- * A deterministic, ordered, canonical-JSON-comparable projection of everything the store
- * holds. The kill matrix compares THIS across an interrupted and an uninterrupted history —
- * never raw database bytes, whose page layout is not deterministic (D-03).
- */
 interface JobStoreDump {
     readonly schemaVersion: number;
     readonly epoch: number;
@@ -405,7 +160,6 @@ interface JobStorePort {
      * Adopting an epoch BELOW the recorded one is refused: authority only moves forward.
      */
     adoptEpoch(epoch: number): Promise<JobStoreFence>;
-    /** Fence-free by design — see the D-02/D-07 note at the top of this module. */
     enqueue(request: JobInsert): Promise<JobEnqueueOutcome>;
     /**
      * Offer the next claimable row, honouring an optional kind exclusion in the SELECTION
@@ -418,24 +172,7 @@ interface JobStorePort {
      * that must BEHAVE differently.
      */
     claimNext(fence: JobStoreFence, options?: ClaimNextOptions): Promise<JobClaimOutcome>;
-    /**
-     * Terminate one job and enqueue its declared successors in the SAME transaction. Two
-     * verbs would leave a window where a crash loses the chain; one verb has no window.
-     *
-     * `chainTerminal`, when supplied, joins that same transaction (388 D-09): the notification
-     * a replayed terminal re-attempts dedupes on a unique index rather than on a caller's
-     * memory of having written it.
-     */
     completeAndChain(jobId: JobId, next: readonly JobInsert[], fence: JobStoreFence, chainTerminal?: ChainTerminalRecord): Promise<JobCompleteOutcome>;
-    /**
-     * Land one permanent failure and enqueue every declared continuation in the SAME fenced
-     * transaction. A stale or crashing host therefore exposes neither half or both halves,
-     * never a terminal parent with a partial chain (or an orphaned chain with a live parent).
-     *
-     * Carries the same optional chain-terminal record as its sibling, and that symmetry is
-     * D-12: a failure is exactly when the user most needs to hear from the chain, so the
-     * notification cannot live on the success path alone.
-     */
     failAndChain(jobId: JobId, disposition: Extract<JobFailureDisposition, {
         readonly kind: 'permanent';
     }>, next: readonly JobInsert[], fence: JobStoreFence, chainTerminal?: ChainTerminalRecord): Promise<JobFailAndChainOutcome>;
@@ -447,14 +184,6 @@ interface JobStorePort {
      * cross-process projection, but that projection never becomes the source of authority.
      */
     publishCheckpoint(jobId: JobId, checkpointId: string, payload: JobCheckpointRecord, fence: JobStoreFence): Promise<void>;
-    /**
-     * Ask for a job to stop, and report what that meant for the job it found (D-19).
-     *
-     * Fenced like every other verb that moves a job, and for the sharper reason: a writer that
-     * has lost its lease could otherwise cancel work the current writer is actively running.
-     * One transaction, so the decision between "stop it now" and "ask it to stop" is made
-     * against the same row state it is then written to.
-     */
     requestCancel(jobId: JobId, fence: JobStoreFence): Promise<JobCancelOutcome>;
     /**
      * Land a job that was asked to stop, releasing its claim. THE DRIVER'S verb, not a caller's.
@@ -465,19 +194,6 @@ interface JobStorePort {
      * what keeps `cancelled` unreachable except through the two-step path.
      */
     recordCancellation(jobId: JobId, fence: JobStoreFence): Promise<void>;
-    /**
-     * Return a FINISHED job to the queue, forgetting what its last attempt recorded.
-     *
-     * Terminal is exactly `done | failed | cancelled` — the store's own `TERMINAL_JOB_STATUSES`
-     * — and anything else answers `not-terminal` having moved nothing. The lifecycle reset and
-     * the checkpoint forget are ONE fenced transaction, because a row that reads `queued` while
-     * its checkpoints still exist is precisely the state that replays a stand-in's recorded
-     * authorship as though a handler had produced it.
-     *
-     * An id no row answers to raises the store's existing not-found error rather than gaining a
-     * third outcome arm (413-02 D-4): the outcome union describes what the store found a JOB
-     * to be, and a mismatched id is a caller bug, not data.
-     */
     requeueTerminal(jobId: JobId, fence: JobStoreFence): Promise<JobRequeueOutcome>;
     /**
      * Read-side: no fence, because reading claims no authority.
@@ -500,13 +216,6 @@ interface JobStorePort {
 interface JobModelRequest {
     readonly system?: string;
     readonly prompt: string;
-    /**
-     * Optional image parts riding the SAME request (389 D-02). Screenshots are
-     * capability-gated per the v46 negotiation the host binding surfaces as `vision` below:
-     * an author attaches evidence bytes here only when the capability advertises vision AND
-     * a blob reader is bound. Absent means a text-only request — the L9 graceful-degradation
-     * posture — and every pre-widening caller and stub stays assignable unchanged.
-     */
     readonly images?: readonly Uint8Array[];
     readonly signal?: AbortSignal;
 }
@@ -514,23 +223,8 @@ interface JobModelRequest {
 interface JobModelOutput {
     readonly text: string;
 }
-/**
- * The model, as a job may see it (D-11 layer 2).
- *
- * A TYPE, never an import: a job handler receives a value shaped like this from exactly one
- * place — the author callback's parameter — and the barrel publishes no accessor that could
- * produce one. `modelId` is here so a checkpoint's provenance is recordable without the engine
- * having to know anything else about the binding.
- */
 interface JobModelCapability {
     readonly modelId: string;
-    /**
-     * Whether the bound model accepts image parts (389 D-02) — the v46 capability
-     * negotiation surfaced as one flag by the host binding. OPTIONAL and absent means
-     * text-only: a text-only BYOM binding and every existing stub keep compiling and keep
-     * their L9 posture without declaring anything. Nothing else in the memoization
-     * contract moves with this flag.
-     */
     readonly vision?: boolean;
     generate(request: JobModelRequest): Promise<JobModelOutput>;
 }
@@ -597,57 +291,18 @@ interface ParsedDraftLike {
     readonly filePath: string;
     /** Identity half two: the parsed test's display name, as `PerTestOutcome.testName`. */
     readonly testName: string;
-    /**
-     * The parsed test's `target` — the name `agent-qa run` resolves against the config.
-     *
-     * REQUIRED, exactly as `TestDefinitionSchema` requires the key: a document that carries none is
-     * not a parsed test at all, so an optional mirror here would be a second, weaker answer to what
-     * the parser already decided.
-     *
-     * IT IS HERE BECAUSE IT IS CHECKED, and unlike `context` it is checked precisely because it is
-     * NOT editable (394-37, WR-04). `runs.start` types this value into a live application:
-     * `resolveTarget` throws on a name the config does not declare, inside a real child process, up
-     * to `DRAFT_STABILITY_RUNS_N` times — and `target` is outside `EDITABLE_POINTER_ROOTS`, so no
-     * repair patch may correct it. The one place that can refuse it cheaply is the compile stage,
-     * which already holds the vocabulary it serves the prompt; this field is what lets it compare.
-     */
     readonly target: string;
-    /** Pre-interpolation NL step text. Post-interpolation text can carry resolved secrets (D-19). */
+    /** Pre-interpolation NL step text. Post-interpolation text can carry resolved secrets. */
     readonly steps: readonly string[];
-    /**
-     * The parsed test's `context` block, pre-interpolation, optional exactly as
-     * `TestDefinitionSchema.context` is — post-interpolation text can carry resolved secrets (D-19).
-     *
-     * IT IS HERE BECAUSE IT IS EDITABLE. `context` is one of the three `EDITABLE_POINTER_ROOTS`, so
-     * a patch can write it; a mirror that omitted it made the credential gate blind to a whole root
-     * by TYPE SHAPE rather than by a missed entry in a locations array.
-     */
     readonly context?: string;
     /** Digest of the draft bytes evaluated, so a later edit cannot inherit this receipt. */
     readonly contentDigest: string;
 }
-/**
- * The run capability, shaped as the `runs.start` / `runs.get` op pair (D-02, op-calls-op).
- *
- * There is no second in-host marker-stamping site: the evaluator asks for a gate-run through the
- * same input contract every other caller uses, and the runner stamps the handoff. What the
- * evaluator does with the acknowledgment is CONFIRM — `runs.start` copies both markers off the
- * durable record rather than echoing the request, so an acknowledgment that comes back without
- * them is the host saying the run was not accepted as a gate-run.
- */
 interface DraftRunPortLike {
     start(input: RunsStartInput): Promise<RunStartAcknowledgement>;
     get(runId: string): Promise<CompletedRunHandoff | undefined>;
 }
-/**
- * The suite-fingerprint read port (D-15), mirroring `createSuiteFingerprintIndex`'s three verbs.
- *
- * Synchronous, because the real implementation reads a local SQLite table and is. Partition
- * scoping is the binder's job: the real factory REQUIRES a product, so a bound index is already
- * scoped and this shape has no scoping knob to get wrong.
- */
 interface SuiteFingerprintIndexLike {
-    /** The union D-14's novel-element test compares against. Empty table, empty union. */
     elementUnion(): ReadonlySet<string>;
     /** The identities that HAVE fingerprint rows — the fingerprint lane's population. */
     coveredTests(): readonly SuiteTestIdentity[];
@@ -659,49 +314,15 @@ interface SuiteTestIdentity {
     readonly filePath: string;
     readonly testName: string;
 }
-/**
- * One suite test as TEXT, for D-16's degraded lane.
- *
- * The population is the authored-test universe MINUS `coveredTests()` — an evidence-less test is
- * one the derived index has no rows for, which the index deliberately does not conflate with
- * "uncovered". Building that difference is the host's job: the suite is not a fact the derived
- * index owns.
- *
- * Carries no `title` beside `testName`. A parsed test has ONE display name, so a separate title
- * field would be two spellings of one fact and a reader would have to guess which of them the
- * similarity actually reads.
- */
 interface SuiteTextCorpusEntryLike {
     readonly filePath: string;
     readonly testName: string;
     /** Pre-interpolation step text, same rule as the draft's. */
     readonly stepsText: readonly string[];
 }
-/**
- * The durable receipts store (D-19), mirroring `createDraftReceiptsStore`'s write verb.
- *
- * Only `put` — this evaluator writes and never reads back. The real store's `get`/`list` exist for
- * 394's proposal envelope, and a port that named verbs its holder never calls would invite a
- * binder to supply implementations nothing exercises.
- */
 interface DraftReceiptsStoreLike {
     put(receipt: DraftReceipt): Promise<void>;
 }
-/**
- * The READ half of the same store (394-07, D-12 · WTST-05) — the funnel's whole substrate.
- *
- * A SECOND, NARROWER MIRROR rather than a `list` member added to the write port above, and the
- * split is the point: the evaluator writes and never reads back, and the funnel reads and never
- * writes. One port carrying both verbs would let a composition hand the funnel projection a
- * capability to overwrite the very records it is reporting on — and the whole claim of D-12 is
- * that nothing new is persisted, which is easier to keep when the projection is structurally
- * unable to persist anything.
- *
- * `list()` and nothing else. The real store's `get(contentDigest)` exists, and the funnel has no
- * use for it: a funnel is about a POPULATION, and a port able to fetch one receipt by address
- * would invite a projection that walked digests it learned somewhere else — a second denominator
- * beside the one `list()` defines.
- */
 interface DraftReceiptsReadPortLike {
     list(): Promise<DraftReceipt[]>;
 }
@@ -723,52 +344,11 @@ interface DraftReceiptsReadPortLike {
 interface AuthoringReadPortLike {
     getAuthoringBrief(intent: string, scope: ScopeKey): Promise<AuthoringBrief>;
     suiteTextCorpus(): Promise<readonly SuiteTextCorpusEntryLike[]>;
-    /**
-     * The names a `target` may legally take in this project (394-33, WR-07).
-     *
-     * A VOCABULARY, NOT A DERIVATION, and that is the whole of what it fixes. `TestDefinitionSchema`
-     * requires a `target`, nothing validates one before `runs.start` types it into a live
-     * application, and `target` is outside `EDITABLE_POINTER_ROOTS` so no repair patch can correct
-     * it — yet stage 3's prompt asked for the value while serving no list to choose from. The Scope
-     * block is not that list: `deriveDefaultAuthoringScope` answers a PRODUCT
-     * (`target.product ?? targetName`), so on any project where a target declares a product under a
-     * different name, the scope key is not a configured target at all.
-     *
-     * A THIRD VERB ON THE READ HALF rather than a port of its own, on this interface's own stated
-     * reasoning: it is a READ of this project's own state through capabilities the composition root
-     * already holds, and a host that can serve the brief and the suite corpus but not the names its
-     * own config declares does not exist. It is deliberately NOT on `AuthoringScopePortLike` — that
-     * port answers WHICH SCOPE THIS PROJECT AUTHORS FOR and can legitimately refuse; this one
-     * enumerates and never refuses. An empty array is a legitimate answer (a config declaring no
-     * targets), and the block a reader is served says so in words rather than rendering nothing.
-     */
     configuredTargetNames(): Promise<readonly string[]>;
 }
-/**
- * The host's answer to "which scope does this project author for?" when the caller named none.
- *
- * SEPARATE FROM {@link AuthoringReadPortLike} rather than a third verb on it, because the two are
- * different facts about a host. The read half needs a knowledge index; this needs the resolved
- * config and the workspace's committed tests, and a host can genuinely have one without the
- * other. Bundling them would make a composition that can derive a scope but serve no brief report
- * the whole read half absent.
- *
- * IT EITHER ANSWERS OR IT THROWS, and there is no third arm. A `ScopeKey | undefined` would put
- * the never-guess decision back at the op, one layer from the evidence — the host is the only
- * side that knows WHICH candidates it saw, and D-19's posture is that a refusal names them.
- */
 interface AuthoringScopePortLike {
     deriveDefault(): Promise<ScopeKey>;
 }
-/**
- * What staging a compiled draft produced — parsed and written, or refused and NOT written.
- *
- * The refusal arm is the T-394-06 mitigation expressed as a return type. Model-authored YAML is
- * the one input on this path that no schema at the op boundary can vet, so it is parsed before it
- * becomes a file; a shape that could only answer "here is your path" would have forced the caller
- * to discover an unparsable draft one stage later, from the verify op, with the bytes already on
- * disk.
- */
 type DraftStageOutcome = {
     readonly kind: 'staged';
     readonly draft: ParsedDraftLike;
@@ -796,70 +376,12 @@ type DraftStageOutcome = {
  * draft's own member.
  */
 interface DraftShelfPortLike {
-    /**
-     * The model stage 3 authors with — built by the host through `createModel` (389 D-04).
-     *
-     * A FACTORY and not an object, on the composition root's own `model` idiom: a model is
-     * resolved at most once and lazily, when something actually needs one, so a composition can
-     * bind this capability without constructing a client for a host that never authors a draft.
-     */
     model(): Promise<JobModelCapability>;
     /** Parse, then write, in that order. An unparsable draft leaves nothing on disk. */
     write(contents: string): Promise<DraftStageOutcome>;
-    /**
-     * Apply an RFC-6902 patch set to a staged draft and stage the result (394-06, D-09/D-20).
-     *
-     * THE ONE PATCH APPLIER, REACHED THROUGH A PORT RATHER THAN AN IMPORT. `applyPatchSetToTestDoc`
-     * lives in `core` — it needs the yaml CST so untouched nodes keep their source bytes — and this
-     * package may not depend on `core` at all (the FUNC-02 firewall stated at the top of this file).
-     * The host binds this verb over that applier, so the repair loop and the user-facing edit op are
-     * two consumers of one contract, which is the property a patch vocabulary with a single consumer
-     * cannot keep.
-     *
-     * It answers the SAME `DraftStageOutcome` the whole-document `write` answers, and for the same
-     * reason: what comes back from a model cannot be trusted to still be a runnable test document
-     * after it is applied, so the result is parsed before it is anything else, and an unparsable
-     * result leaves the shelf as it was.
-     */
     applyPatches(draft: ParsedDraftLike, patchSet: TestEditPatchSet): Promise<DraftStageOutcome>;
-    /**
-     * The run capability stage 5 reads evidence through and the repair arm probes with (394-06).
-     *
-     * ON THIS BUNDLE rather than as a fourth loop dep, on the bundle's own stated reasoning: none of
-     * these capabilities is independently bindable. `verifyDraft` already dispatches an op that
-     * starts gate runs, so a host that can verify a draft can start and read one by construction —
-     * a shelf bound without this would be a host that can ask whether a draft is any good and cannot
-     * look at the runs that answered.
-     *
-     * It is the HANDOFF reader (`DraftRunPortLike.get`) and not `runs.get`'s projection, because the
-     * router decides on per-step execution evidence — terminations, planning failures, cycle flags —
-     * and none of that survives a `RunDetail`, whose only step-shaped field is a count.
-     */
     readonly runs: DraftRunPortLike;
-    /**
-     * Stage 4, dispatched as the REGISTERED `authoring.draft.verify` op (D-01, op-calls-op).
-     *
-     * A closure the composition root mints over the registry it is building, exactly as
-     * `createDraftEvaluation`'s `startGateRun` is minted over the same deferred reference — it is
-     * how a registered op reaches a sibling registered op without this package being able to name a
-     * registry. It rides THIS bundle rather than a dep of its own because it is not independently
-     * bindable either: a host that can compile and stage a draft but cannot verify one would author
-     * a test and then have nothing to say about whether it is worth keeping, which is the one answer
-     * the loop exists to produce.
-     */
     verifyDraft(input: AuthoringVerifyDraftInput): Promise<DraftReceipt>;
-    /**
-     * Write a staged draft's bytes to its test path (432 D-06/D-07). The direct final-test writer.
-     *
-     * ON THIS BUNDLE because it is not independently bindable either: a host that can stage a draft
-     * on its shelf is the host that can put those bytes in its suite. The host keeps the guards the
-     * old accept kept — the target must lie inside the workspace and still hold the bytes the caller
-     * read (`sourceDigest`, absent for a new test) — writes through a sibling temp and a rename, and
-     * runs no git. A write that did not land answers `not-written` with its reason, never `written`.
-     *
-     * THE LOOP DECIDES WHETHER TO CALL IT, from the disposition (`draftDispositionWritesTarget`); the
-     * writer never sees one. A rejected draft is simply never handed to it.
-     */
     publish(request: TestFilePublishRequestLike): Promise<TestFileWrite>;
 }
 /** One final draft to write: the shelf copy, where it goes, and what that path held when read. */
@@ -884,32 +406,10 @@ interface TestFilePublishRequestLike {
  * that into the honest `no-history` posture rather than into a clean bill of health.
  */
 interface SuiteOutcomeHistoryPortLike {
-    /**
-     * The stable identities the target suite file has run evidence for, in ONE product.
-     *
-     * `product` LEADS BOTH VERBS because the projection these read is keyed
-     * (product, filePath, testName) and nothing else is a stable identity there. A port shaped
-     * without it could only be bound by guessing a product or by serving every product's history
-     * under one file path — and the second would report another application's flakiness as this
-     * target's, which is the whole failure the message exists to avoid (T-394-68).
-     */
     testsIn(product: string, filePath: string): Promise<readonly SuiteTestIdentity[]>;
     /** One identity's recorded member outcomes, newest last. */
     outcomesFor(product: string, filePath: string, testName: string): Promise<readonly string[]>;
 }
-/**
- * The capability `authoring.funnel.get` binds through — the funnel's reads, bundled.
- *
- * 2026-10-01 (432-17, D-06): the proposals inbox read is deleted with the inbox. An authored test
- * that a keep-gate did not reject is written in its own call, so no person accepts it afterwards
- * and nothing records such a decision. The terminal stage reads the receipts alone (see
- * {@link projectAuthoringFunnel}).
- *
- * THE STABILITY HALVES RIDE THE SAME BUNDLE for the same argument, and they are OPTIONAL within
- * it: a host may genuinely have receipts and no outcome projection, and D-14's whole point is
- * that a missing history reads as `no-history` rather than as a refusal. What is NOT here is any
- * way to start a run.
- */
 interface AuthoringFunnelPortLike {
     readonly receipts: DraftReceiptsReadPortLike;
     readonly outcomes?: SuiteOutcomeHistoryPortLike;
@@ -926,32 +426,7 @@ interface AuthoringFunnelPortLike {
  * order, which is why the sort is stable rather than a comparator that reorders equal instants.
  */
 declare function scopeReceiptsToWindow(receipts: readonly DraftReceipt[], window: AuthoringFunnelWindow): readonly DraftReceipt[];
-/**
- * Project the funnel over one window.
- *
- * `dedupRefusals` is deliberately left ABSENT: a stage-2 refusal ends the invocation with nothing
- * authored — no draft, no receipt and no gate-run (D-04) — so nothing on this host durably records
- * one, and reporting `0` would say "no author was ever refused" about something nothing counts.
- *
- * THE TERMINAL STAGE IS READ OFF THE RECEIPTS (2026-10-02, quick 261002-ctr). It was `accepted`,
- * applied decisions read off `test-draft` proposal envelopes. Since 432-08 a draft a keep-gate did
- * not reject is written to its test path in the call that authored it and nothing is filed, and
- * 432-17 deleted the inbox, so `accepted` read 0 on every host. `writeEligible` counts the receipts
- * whose stored disposition D-06 writes, which `computeAuthoringFunnel` reads itself, so this
- * projection hands it nothing but the window's receipts.
- */
 declare function projectAuthoringFunnel(window: AuthoringFunnelWindow, port: AuthoringFunnelPortLike): Promise<AuthoringFunnel>;
-/**
- * Gather the target's existing tests and assess them. STARTS ZERO RUNS.
- *
- * The draft's OWN identity is excluded from its neighbours: a draft under evaluation is not
- * evidence about the suite it is trying to join, and counting its own flip as a neighbour's
- * would let every mixed verdict explain itself.
- *
- * An unbound outcome port is `no-history` rather than a refusal, which is D-14's degraded posture
- * arriving through the composition instead of through a special case: a host that cannot read the
- * projection genuinely has no history to report, and saying so is the honest answer.
- */
 declare function gatherSuiteStability(input: {
     /**
      * The partition the outcome projection keys on — `slugBranch` of the run's own scope, as the
@@ -965,39 +440,9 @@ declare function gatherSuiteStability(input: {
 
 /** A dotted config path's new value. The three scalar shapes a config field can hold. */
 type ConfigFieldValue = string | number | boolean;
-/**
- * A value of any shape the configuration format can hold (395-05).
- *
- * SCALARS ARE NOT ENOUGH ONCE MORE THAN ONE OP WRITES. `config.field.set` addresses one leaf, so its
- * DTO's scalar union was the whole vocabulary. `config.target.create` writes a target ENTRY — a map
- * of `platform`, `url` and possibly an auth binding — and `config.hook.add` writes a hook ENTRY into
- * a sequence. Composing those out of several scalar writes would mean several parses of the same
- * file, each free to disagree with the last about what it was editing, for an edit a person reads as
- * one block.
- *
- * IT IS THE FORMAT'S VOCABULARY, NOT ANY OP'S. Three scalars, sequences and maps is what yaml holds;
- * nothing here names a target, a hook or a plugin. A per-op value type would be the mutation fork
- * this phase's construction pipeline exists to avoid.
- */
 type ConfigStructuredValue = ConfigFieldValue | readonly ConfigStructuredValue[] | {
     readonly [key: string]: ConfigStructuredValue;
 };
-/**
- * What the document holds at a path, as a STRUCTURAL fact rather than as a value (395-05).
- *
- * WHY THIS EXISTS AT ALL: three of this phase's ops have to answer a question about the document
- * before they may mutate it. Does `registry.targets.shop` already exist (a create is never an
- * upsert)? Does it exist at all (an edit of an absent target is a typed not-found, and 387's
- * never-guess posture says the refusal lists the names that DO exist)? How long is the hook
- * sequence, so an append writes past its end rather than over its last member? `packages/agent`
- * cannot parse yaml — its ownership contract pins external dependencies at `['ai', 'zod']` — so the
- * document's shape is a host fact exactly as its bytes are.
- *
- * IT ANSWERS SHAPE, NEVER CONTENT, and the line is drawn there deliberately. `keys` and `length`
- * describe the container; the values inside it are not returned. A port that answered "what is at
- * this path" would be a second, unmasked config reader — the capability `ConfigReaderPort`'s header
- * says must not exist — reached through the back door of a mutation helper.
- */
 interface ConfigPathFacts {
     /** The dotted path this fact is about, echoed so a caller reading several cannot misalign them. */
     readonly path: string;
@@ -1016,123 +461,36 @@ interface ConfigFileBytes {
     /** Absent means the file is not there — a fact, never a zero-length stand-in for one. */
     readonly bytes?: Uint8Array;
 }
-/**
- * The config file SET, enumerated — never matched.
- *
- * A SET AND NOT A GLOB (394-39's population lesson, RESEARCH Pitfall 5). The host derives the
- * members from the config itself — the config yaml, the hooks file it names, the managed gitignore
- * block — so "which files are config" has one answer that a porcelain check, an out-of-set
- * classifier and an apply all read. A pattern would answer differently on the first repository
- * whose layout nobody anticipated, and it would do so silently.
- */
 interface ConfigFileSet {
     /** Which member of {@link ConfigFileSet.files} is the config yaml a field edit addresses. */
     readonly configFile: string;
-    /**
-     * Which member is the hooks file (395-05).
-     *
-     * NAMED RATHER THAN GUESSED. `config.hook.add` writes this member and no other, and the two ways
-     * to find it without being told are both wrong: matching on `hooks.yaml` ignores the fact that
-     * `workspace.hooksFile` can name anything, and "the yaml that is not the config" breaks the day
-     * the set grows a third yaml. The host reads the name from the config it just parsed, which is the
-     * same read `enumerateConfigFileSet` was given.
-     */
     readonly hooksFile: string;
     readonly files: readonly ConfigFileBytes[];
 }
-/**
- * What the comment-preserving edit produced, and what it replaced.
- *
- * `previousValue` RIDES THE SAME PARSE THAT WROTE THE NEW ONE (395-04, D-02). The per-value
- * cross-boundary classifier has to compare the committed value against the proposed one — a base URL
- * pointing at a NEW origin is the case a per-op map cannot see — and the only alternative to
- * returning it here was a second read of the same bytes through a second parse, free to disagree
- * with the one the mutation actually applied. One parse answers both halves of one edit.
- *
- * ABSENT MEANS "there was no scalar there": either the path held nothing, or it held a map or a
- * sequence. Both are true statements about what the edit replaced, and neither is a value an origin
- * comparison can be taken over — a wholesale subtree replacement is flagged on its own grounds
- * (secret-adjacency) rather than by pretending its old value was a string.
- */
 interface ConfigFieldSetResult {
     readonly bytes: Uint8Array;
     readonly previousValue?: ConfigFieldValue;
 }
 interface ConfigFilesPortLike {
-    /** Re-read the committed set. Called at PROPOSAL time, which is CFGM-04's own law. */
     read(): Promise<ConfigFileSet>;
-    /**
-     * The typed field mutation, comment-preserving, over exactly the bytes it was handed.
-     *
-     * TAKES THE BYTES RATHER THAN RE-READING THEM. The caller has just re-read the file and is about
-     * to digest what it read; a mutation that opened the file again would edit a version the digest
-     * is not about, which is a freshness hole inside the freshness contract.
-     *
-     * 395-05 WIDENED `value` from a scalar to {@link ConfigStructuredValue}. See that type's header:
-     * the widening is the yaml FORMAT's vocabulary arriving in full, not an op's shape leaking into
-     * the port. `previousValue` still answers scalars only, because that is the only case an origin
-     * comparison can be taken over.
-     */
     setField(input: {
         readonly bytes?: Uint8Array;
         readonly path: string;
         readonly value: ConfigStructuredValue;
     }): Promise<ConfigFieldSetResult>;
-    /**
-     * What the document HOLDS at each path, structurally (395-05). See {@link ConfigPathFacts}.
-     *
-     * EVERY PATH IN ONE CALL, SO EVERY ANSWER COMES FROM ONE PARSE. An op that asked twice could be
-     * told the target is absent and then, from a second parse of the same bytes, be given a key list
-     * that contains it. The bytes are handed in for `setField`'s reason, one paragraph up.
-     */
     inspect(input: {
         readonly bytes?: Uint8Array;
         readonly paths: readonly string[];
     }): Promise<readonly ConfigPathFacts[]>;
-    /**
-     * A fresh canonical hook id (395-05).
-     *
-     * A HOST FACT FOR THE REASON `mintProposalId` IS ONE. `core`'s `HookDefinitionSchema` refuses any
-     * id `isCanonicalHookId` does not accept — `h_` followed by ten id-agent words — and that mint
-     * lives in `@vostride/agent-qa-ids`, which is not among this package's internal dependencies. It
-     * also draws randomness, and nothing in `packages/agent` reads a clock or an entropy source. A
-     * hand-formatted id would be the "don't hand-roll" row of this phase's research arriving as a
-     * defect: it would parse as a string, be written into a person's repository, and be refused by
-     * the hooks schema at the next run rather than at the proposal.
-     */
     mintHookId(): string;
 }
-/**
- * One thing whole-config validation said, and the file it said it ABOUT (395-10 · WR-11).
- *
- * THE MESSAGE IS THE VALIDATOR'S OWN WORDS; the path is not. This layer neither classifies nor
- * renders the words — a closed issue vocabulary here would be a second, weaker copy of `core`'s
- * schema refinements, out of date the first time one of them is added — but WHICH FILE an issue is
- * about is a fact the validator alone knows, and a string that had already joined the two could
- * only be split again by parsing it back apart.
- *
- * WHY IT IS SPLIT AT ALL. A blocked record's `paths` used to be the DIFFED files, so a proposal
- * that edited the config yaml and was refused because the committed hooks file does not parse named
- * the one file that was fine. A person following that reference finds nothing wrong and re-tries the
- * edit. The pipeline now unions these paths into the record's, which it can only do if the path
- * arrives as a path.
- */
 interface ConfigValidationIssue {
     /** The config-set member the issue is about — never a dotted config path. */
     readonly path: string;
-    /**
-     * The validator's own sentence. It may contain a dotted config path; it may not contain a VALUE.
-     *
-     * THE SECOND HALF IS A CONTRACT AND NOT A HOPE, and 395-10 is where it was learned: the vendored
-     * `yaml` package pretty-prints a parse error with a verbatim excerpt of the offending source line,
-     * and an implementation that interpolated that error text published whatever that line held onto
-     * three surfaces. A message derived from a library's error must be reduced to the facts this
-     * product chose to publish — for a parse failure, its POSITION.
-     */
     readonly message: string;
 }
 /**
- * What whole-config validation said about the candidate config (CFGM-01).
+ * What whole-config validation said about the candidate config.
  */
 type ConfigValidation = {
     readonly ok: true;
@@ -1141,21 +499,6 @@ type ConfigValidation = {
     readonly issues: readonly ConfigValidationIssue[];
 };
 interface ConfigValidatePortLike {
-    /**
-     * The WHOLE CANDIDATE SET as it would stand after the mutation — never the changed field alone,
-     * and since 395-05 never the changed FILE alone either.
-     *
-     * THE SET, BECAUSE THE CONFIG IS MORE THAN ONE FILE. `config.hook.add` writes the hooks file and
-     * leaves the config yaml untouched; a validator that only ever saw the config yaml would have
-     * declared that proposal valid without reading the only bytes it changed. D-03's law is that the
-     * guards here are WHOLE-INPUT by construction, and the whole input is the pinned file set: the
-     * host validates each member it has a schema for (the config yaml against `core`'s
-     * `AgentQaConfigSchema`, the hooks file against `HooksFileSchema`) and passes over the ones it
-     * does not (`.gitignore` is a member of the set and has no schema).
-     *
-     * MEMBERS WITH NO BYTES ARE ABSENT FILES, and absent is a legal state for every member but the
-     * config yaml — a project with no hooks file is an ordinary project, not an invalid one.
-     */
     validate(input: {
         readonly configFile: string;
         /** The hooks file member, so the validator picks a schema by NAME rather than by extension. */
@@ -1164,12 +507,6 @@ interface ConfigValidatePortLike {
         readonly files: readonly ConfigFileBytes[];
     }): Promise<ConfigValidation>;
 }
-/**
- * What a direct field change did to the config yaml (2026-09-30, 432-07 D-05/D-07).
- *
- * `applied` names the revision the change merged onto, which is the file as it stood in the
- * change's own turn and so includes any outside edit made meanwhile. A refusal wrote nothing.
- */
 type ConfigFieldWriteOutcome = {
     readonly kind: 'applied';
     /** The config member, workspace-relative. */
@@ -1192,13 +529,6 @@ interface ConfigFilePublication {
     readonly baseDigest?: string;
     readonly bytes: Uint8Array;
 }
-/**
- * What a multi-file publication actually did (432-07 D-05/D-07).
- *
- * `refused` is decided before any write. `interrupted` is a later failure, and `written` names
- * exactly the files that now hold their new bytes. There is no rollback and no journal: the files
- * are plain edits a person reverts with git.
- */
 type ConfigFilePublishOutcome = {
     readonly kind: 'published';
     readonly written: readonly string[];
@@ -1217,16 +547,6 @@ type ConfigFilePublishOutcome = {
     };
     readonly unwritten: readonly string[];
 };
-/**
- * The direct config writer (2026-09-30, 432-07 D-05/D-07): generated changes publish in the call
- * that made them, with no proposal and no git.
- *
- * FIELD CHANGES STAY FIELD CHANGES until the host rereads the file in that path's write turn, the
- * turn the dashboard's own autosave takes, so an outside edit to another field is kept and a stale
- * `expect` refuses. Whole files (a hooks file, the managed `.gitignore` block, a scaffold) are
- * checked against the digest they were built from and written one at a time, each atomically.
- * The queue is per process; nothing here claims a cross-process lock.
- */
 interface ConfigWritePortLike {
     applyFields(request: {
         readonly changes: readonly ConfigChange[];
@@ -1235,35 +555,6 @@ interface ConfigWritePortLike {
         readonly files: readonly ConfigFilePublication[];
     }): Promise<ConfigFilePublishOutcome>;
 }
-/**
- * The scaffold's CONTENT, rendered by the host that owns it (395-08, D-04 · CFGM-05).
- *
- * A PORT BECAUSE THE CONTENT LIVES IN `cli` AND `agent` MAY NOT IMPORT IT. D-04's whole claim is
- * that `agent-qa init` and `config.project.scaffold` write ONE substance; the substance is the
- * default config derivation, the yaml comment injection, the hooks template and the managed
- * `.gitignore` block, and all four live beside `init`'s filesystem machinery in
- * `commands/scaffold-content.ts`. Copying any of it here would mint the second scaffold D-04
- * exists to prevent, and the copy would fail silently — a person's proposal and their `init` would
- * simply produce different projects.
- *
- * IT TAKES THE DERIVATION, NOT THE DOMAIN. `targetName` and `baseUrl` are what
- * `parseHostnameToken` produced; handing the raw token over would put the derivation on both sides
- * of the boundary and let the host answer a different one than the gate pinned.
- *
- * `existingGitignore` IS BYTES, ABSENT WHEN THERE IS NO FILE. The block is an UPSERT: a project
- * with a `.gitignore` of its own gets the managed block appended to what it already has, and the
- * proposal's diff shows exactly that. Absent and empty are deliberately different — the first is
- * a file the apply CREATES, the second a file it rewrites.
- *
- * `existingConfig` IS THE SECOND MODE OF THE ONE PRODUCER (395-12, D-04 · CFGM-05), and it is a
- * MODE rather than a second port because D-04's claim is that there is one substance: a second
- * renderer would be exactly the drift D-04 exists to make impossible. Present when the project HAS
- * a configuration that declares no targets — the class SC-5 has to serve, because a project able to
- * hold a conversation at all is one whose `registry.llms` lives in a config file. In that mode the
- * producer inserts exactly `registry.targets.<targetName>` into the person's own bytes through the
- * comment-preserving Document API and emits no other change to that file. Absent means from zero,
- * and the from-zero render is byte-for-byte what it was before this field existed.
- */
 interface ConfigScaffoldContentPortLike {
     render(input: {
         readonly targetName: string;
@@ -1303,101 +594,38 @@ interface ConfigScaffoldMergeTarget {
     readonly hooksPresent: boolean;
 }
 
-/**
- * The abstention coverage record (D-11).
- *
- * `query` is verbatim, and it is why this record is written to a LOCAL append-only log and to
- * nothing else: it is the one free-text value in the feature. SURF-FUT-02 reads the log later to
- * decide whether docs-RAG has demand. An implementation that forwards this to a network sink is
- * the D-14 no-free-text law broken, not a configuration choice.
- */
 interface ExplainAbstentionRecord {
     readonly query: string;
     /** Canonical row ids the deterministic scorer picked — never a model's suggestion. */
     readonly closestRowIds: readonly string[];
 }
-/**
- * What the `explain` op needs from its host, and the whole of it.
- *
- * Bound at `composeLocalAgent()` (385 D-15) by plan 07. An unbound composition refuses BY NAME
- * through `FunctionNotBoundError` rather than degrading to a model-only answer — an explain that
- * silently loses its catalog is precisely an explain that answers from model memory.
- */
 interface CapabilityCatalogPort {
-    /**
-     * Every catalog row, as data.
-     *
-     * A PRODUCED zero-row catalog is a valid answer here and must not be an error (398-01's loader
-     * makes the same distinction): the renderer turns zero rows into the abstention arm, which is
-     * SC-2's "an empty catalog abstains rather than inventing" at the seam where it is decidable.
-     */
     loadCatalog(): Promise<readonly CatalogRow[]>;
-    /**
-     * The model's selection over the rows it was handed — row ids only (D-10).
-     *
-     * Implementations MUST pass `rows` as the grounding data. Anything cited that is not in `rows`
-     * is a ghost id, and the renderer answers ghosts with a whole-output abstention, so a confused
-     * or injected model degrades to "I am not certain" rather than to a fabricated command.
-     */
     citeCapabilities(query: string, rows: readonly CatalogRow[]): Promise<ExplainCitation>;
-    /** One counter tick for a grounded answer. No payload — D-14 permits a count and nothing more. */
     recordAnswered(): void;
-    /** Append the coverage record, locally (D-11). The demand signal for writing the missing doc. */
+    /** Append the coverage record, locally. The demand signal for writing the missing doc. */
     recordAbstained(record: ExplainAbstentionRecord): void;
 }
 
 interface EvaluateDraftPorts {
     readonly runs: DraftRunPortLike;
     readonly fingerprints: SuiteFingerprintIndexLike;
-    /** D-16's evidence-less population. An empty array is a legitimate answer, not an absent port. */
     readonly textCorpus: readonly SuiteTextCorpusEntryLike[];
     readonly receipts: DraftReceiptsStoreLike;
     /** Injected so a receipt's `evaluatedAt` is pinnable in a test. Defaults to the wall clock. */
     readonly now?: () => number;
-    /**
-     * D-14's read side, consulted ONLY when gate 2 flips (394-17 · WTST-05).
-     *
-     * ONE BUNDLE OF TWO HALVES that are useless apart, on the `AuthoringFunnelPortLike` reasoning
-     * one level down. `port` is the funnel's read bundle — which carries NO run capability at all,
-     * so the zero-runs law is structural rather than remembered. `product` is the partition the
-     * projection is keyed on, and it is a THUNK because the answer is OBSERVED rather than derived:
-     * a composition learns it from the first gate-run acknowledgement, and D-04 forbids
-     * short-circuiting, so by the time gate 2 can flip at least one run has been acknowledged. It
-     * answers `undefined` when nothing was observed, and the consultation is then SKIPPED —
-     * deriving a product from configuration instead would be a second rule for a fact the write
-     * side already decides, and the first time the two disagreed this message would report another
-     * application's flakiness as this target's (T-394-68).
-     */
     readonly suiteStability?: {
         readonly port: AuthoringFunnelPortLike;
         product(): string | undefined;
     };
 }
 
-/**
- * The projection's key, spelled the way `run_test_outcomes` is keyed: stable test identity
- * is `(product, filePath, testName)` — NEVER `testId`, a per-run explicit id.
- *
- * 390 D-07 adds the FAILURE FINGERPRINT beside the identity, and the two legs answer two
- * different questions: recurrence is counted per `(product, fingerprint)` — the same failure
- * recurring, not the same test — while the quarantine ladder is keyed on the identity, which
- * is what the ledger records. A member with no failing step to key from (a zero-step failure)
- * omits the leg entirely rather than carrying a stand-in: a fabricated key would window a
- * failure against occurrences that are not its own.
- */
 interface RecurrenceQuery {
     readonly product: string;
     readonly filePath: string;
     readonly testName: string;
     readonly fingerprint?: string;
 }
-/**
- * The ladder rung this identity currently sits on (390 D-06/D-17), when it sits on one at all.
- *
- * `expiresAt` is the ISO deadline the ledger recorded. It is optional because `flagged` has no
- * deadline — flagging is visibility, not suppression — and because the ledger is committed text
- * a human may edit, so a recorded deadline is not guaranteed to parse.
- */
 interface RecurrenceLadder {
     readonly state: QuarantineLadderState;
     readonly expiresAt?: string;
@@ -1409,34 +637,9 @@ interface RecurrenceAnswer {
     /** Absent means this identity is on no rung — the clause is the occurrence count alone. */
     readonly ladder?: RecurrenceLadder;
 }
-/**
- * The D-08 recurrence seam: recurrence context is a LIVE join at render time, resolved per
- * call through this provider — never baked into authored parts and never stored as prose.
- *
- * 389 bound this seam to v51's derived run-outcome projection (`readTestOutcomeHistory` +
- * `failureRecurrence`); 390-06 REBOUND the same seam at the same composition root to the
- * fingerprint-keyed recurrence window plus a per-call fold of the committed quarantine ledger,
- * which is what the ladder arms render. The seam itself did not change shape — the query gained
- * a fingerprint and the answer gained a rung. The author's prompt separately consumes failure
- * history as input-for-REASONING (plan 03's forced channel); this join is the rendered-CLAUSE
- * — two different things by decision.
- *
- * `undefined` means the provider has no history for this identity; the renderer answers
- * with an explicit no-history clause, so obligation c is always rendered, honestly.
- */
 interface RecurrenceProvider {
     failureRecurrence(query: RecurrenceQuery): RecurrenceAnswer | undefined;
 }
-/**
- * Compose one verdict's sentence from its typed parts (D-05).
- *
- * Fixed order: resolved-class frame, the quoted grounding observation with its step ref,
- * the discriminator, the recurrence clause (joined LIVE through `provider`), the
- * recommended next action, and the `agentqa://` links (rendered verbatim from
- * `parts.links`, already codec-validated at the artifact boundary; an empty list renders
- * no see-section). Byte-deterministic: the same (verdict, parts, provider answer) yields
- * the same string in every process.
- */
 declare function renderVerdictSentence(verdict: Verdict, parts: VerdictSentenceParts, provider: RecurrenceProvider | undefined, query: RecurrenceQuery): string;
 
 /** What a handler is handed. Checkpoint publication is a capability, never an import. */
@@ -1452,38 +655,9 @@ interface JobHandlerContext {
      */
     readonly payload: unknown;
     publishCheckpoint(checkpointId: string, value: unknown): Promise<void>;
-    /**
-     * The ONE path from a job to a model (D-10 / D-11 layer 2).
-     *
-     * What is absent from this interface is the contract: there is no model member here, and
-     * this member's own signature is the only place a capability appears. A handler therefore
-     * cannot reach a model except by asking this primitive to record the asking — which is what
-     * makes a resumed job's re-invocation impossible by control flow rather than by discipline.
-     * The member set of this interface is pinned for exact equality by a test, so an ambient
-     * accessor cannot be added quietly beside it.
-     */
     readonly recordLlmAuthorship: BoundRecordLlmAuthorship;
 }
-/**
- * What a handler reports (D-17/D-18).
- *
- * 385 plan 02 replaced this module's own outcome shape with the schema DTO. The two were the
- * same concept described twice, and the local one could not say a handler had FAILED at all —
- * a bare optional successor list makes "finished, chaining nothing" and "gave up" identical.
- * The TOPOLOGY of what may chain to what is still declared here, on the kind; only the
- * INSTANCES come back from the handler, which is what keeps an outcome-dependent chain
- * ordinary data while leaving the whole graph auditable in one place.
- */
 type JobHandler = (context: JobHandlerContext) => Promise<JobHandlerOutcome>;
-/**
- * How a kind's retries are spaced (D-18) — DATA, never a function.
- *
- * A callback would let a kind compute its own delay from whatever it liked, including the
- * wall clock, and the engine could then neither describe a kind's retry behaviour without
- * running it nor keep a dump deterministic. As data, the delay for attempt N is a pure
- * function of the policy and N, which is exactly what the driver computes and hands back to
- * whichever host decides when to pump next.
- */
 type JobBackoffPolicy = {
     readonly kind: 'none';
 } | {
@@ -1495,14 +669,6 @@ type JobBackoffPolicy = {
     readonly factor: number;
     readonly maxDelayMs: number;
 };
-/**
- * Everything a fallback continuation is allowed to know.
- *
- * The absences are the contract (D-20 / D-11 layer 2). There is no model capability here and
- * no place to pass one, so a producer cannot invoke a model however it is written — which is
- * what puts the permanent-failure path on the resume-legal side of the queue by construction
- * rather than by review.
- */
 interface FallbackContinuationInput {
     readonly job: Job;
     readonly payload: unknown;
@@ -1516,21 +682,15 @@ interface FallbackContinuationInput {
  * that must return its instances immediately can only compute them from what it was handed.
  */
 type FallbackContinuationProducer = (input: FallbackContinuationInput) => readonly ChainedJobRequest[];
-/**
- * What a kind declares should happen to its chain when it gives up (D-20).
- *
- * `'halt-chain'` enqueues nothing. A producer names the successors the chain proceeds with
- * instead — the analyze-run posture, whose downstream jobs must never wait on a dead head.
- */
 type JobPermanentFailureDisposition = 'halt-chain' | FallbackContinuationProducer;
 interface JobKindDeclaration {
     readonly kind: JobKind;
-    /** `false` means the kind resumes NOTHING after a crash — chat's posture (JOBQ-04). */
+    /** `false` means the kind resumes NOTHING after a crash — chat's posture. */
     readonly checkpointed: boolean;
     /** The complete set of checkpoint ids this kind may publish, in schedule order. */
     readonly checkpointSchedule: readonly string[];
     readonly allowedSuccessors: readonly JobKind[];
-    /** Attempts are spent at CLAIM (D-18), so this bound holds even for a job that never returns. */
+    /** Attempts are spent at CLAIM, so this bound holds even for a job that never returns. */
     readonly maxAttempts: number;
     readonly backoff: JobBackoffPolicy;
     readonly onPermanentFailure: JobPermanentFailureDisposition;
@@ -1548,7 +708,7 @@ declare class UnknownJobKindError extends Error {
     readonly name = "UnknownJobKindError";
     constructor(jobKind: string);
 }
-/** Thrown at construction when a declaration omits a field the engine reads (D-09). */
+/** Thrown at construction when a declaration omits a field the engine reads. */
 declare class IncompleteJobKindDeclarationError extends Error {
     readonly jobKind: string;
     readonly field: string;
@@ -1581,18 +741,12 @@ declare function createJobKindRegistry(declarations: readonly JobKindDeclaration
 interface JobIdSource {
     jobIdFor(kind: JobKind, idempotencyKey: string): JobId;
 }
-/**
- * Thrown when an enqueue arrives without a usable idempotency key (D-08).
- *
- * The type already requires the argument; this covers the empty string, which types cannot
- * exclude and which would silently collapse every keyless caller onto one queue slot.
- */
 declare class MissingIdempotencyKeyError extends Error {
     readonly jobKind: JobKind;
     readonly name = "MissingIdempotencyKeyError";
     constructor(jobKind: JobKind);
 }
-/** Thrown when a handler asks to chain to a successor its kind never declared (D-17). */
+/** Thrown when a handler asks to chain to a successor its kind never declared. */
 declare class UndeclaredJobSuccessorError extends Error {
     readonly jobKind: JobKind;
     readonly successorKind: JobKind;
@@ -1606,16 +760,6 @@ declare class UndeclaredJobCheckpointError extends Error {
     readonly name = "UndeclaredJobCheckpointError";
     constructor(jobKind: JobKind, checkpointId: string);
 }
-/**
- * Raised at a checkpoint boundary when the job being run has been asked to stop (D-19).
- *
- * A thrown sentinel rather than a return value, because the boundary is inside a capability
- * the handler awaits and there is no other way to unwind a handler from underneath. A handler
- * MAY catch it — cooperative cancellation is cooperative — but catching it buys nothing: the
- * next boundary raises it again, and a kind whose handler swallowed every one of them would
- * simply run to the end, which is the same thing that happens to a kind with no boundary at
- * all. The driver catches it, records the cancellation and reports the boundary it stopped at.
- */
 declare class JobCancelledError extends Error {
     readonly jobId: JobId;
     readonly checkpointId: string;
@@ -1627,26 +771,7 @@ interface CreateAgentJobQueueOptions {
     readonly registry: JobKindRegistry;
     readonly clock: ClockPort;
     readonly idSource: JobIdSource;
-    /**
-     * The model a job may author with, bound by the composition root (D-10).
-     *
-     * REQUIRED, and deliberately not defaultable. An optional capability would mean a queue
-     * could be built with none, and the only sensible behaviour for an author callback that
-     * cannot reach a model is to fail somewhere far from the composition that forgot it. Making
-     * it an argument of construction puts that decision where the binding is made. The engine
-     * never calls it: the only thing that happens to this value is that the authorship
-     * primitive hands it to an author callback, carrying the job's signal when a host passed one.
-     */
     readonly model: JobModelCapability;
-    /**
-     * The kinds this host may never claim, fixed when its queue is composed (388-09).
-     *
-     * A CONSTRUCTION option, deliberately not a member of `RunNextJobInput`: whether a host
-     * may claim a kind is a fact about the HOST — which capabilities its composition can bind
-     * — and putting it on the per-call input would make it a decision every pump site
-     * re-makes, with every pump site a place the answers could diverge. Absent means what it
-     * means today: every declared kind is this host's to take.
-     */
     readonly unclaimableKinds?: readonly JobKind[];
 }
 interface RunNextJobInput {
@@ -1659,18 +784,7 @@ interface RanJobOutcomeBase {
     /** The job AS CLAIMED. The store owns what its row says afterwards. */
     readonly job: Job;
     readonly checkpointsPublished: readonly string[];
-    /**
-     * `false` in exactly one case: the attempt bound was already spent when the job was
-     * claimed, so the driver failed it without handing it to its handler (D-18).
-     */
     readonly handlerInvoked: boolean;
-    /**
-     * The payload of the job AS CLAIMED, so a host can attribute this outcome to whatever the
-     * payload names — a run, above all — without going back to the store for a row the job has
-     * already moved past (406 D-16). Optional because the outcome is the engine's fact and the
-     * payload is the caller's: nothing here reads it, and no fabricated outcome must grow a
-     * field to keep compiling.
-     */
     readonly payload?: unknown;
 }
 type RunNextJobOutcome = {
@@ -1682,15 +796,6 @@ type RunNextJobOutcome = {
 }) | (RanJobOutcomeBase & {
     readonly disposition: 'retry-scheduled';
     readonly reason: string;
-    /**
-     * How long a host should wait before pumping this job again, computed from the kind's
-     * declared backoff policy and the attempt just spent.
-     *
-     * Returned rather than applied: 385 ships no dispatcher, and a driver that slept on its
-     * own would be the timer loop this engine deliberately is not. The same value goes to the
-     * store as the disposition's `retryAfterMs`, which stores the row's not-before time from
-     * its own clock and keeps the row out of every claim until then (444.1 D-23).
-     */
     readonly retryDelayMs: number;
     readonly attemptsRemaining: number;
 }) | (RanJobOutcomeBase & {
@@ -1731,14 +836,6 @@ interface AgentJobQueue {
     enqueue(kind: JobKind, payload: unknown, idempotencyKey: string): Promise<JobEnqueueOutcome>;
     /** Claim, run, checkpoint and dispose of exactly one job. Returns when that job is done. */
     runNextJob(input: RunNextJobInput): Promise<RunNextJobOutcome>;
-    /**
-     * Ask for one job to stop (D-19).
-     *
-     * Built with the driver rather than after it. The place a cooperative cancel is honoured is
-     * the seam between declared checkpoints, and that seam only exists inside `runNextJob` —
-     * adding the check later would mean reopening engine core with handlers already written
-     * against it. 385 exposes this on no surface at all; the phases that own job UX do that.
-     */
     cancel(input: CancelJobInput): Promise<JobCancelOutcome>;
     /**
      * Return every outstanding claim to the queue, keeping the attempt each one spent.
@@ -1756,11 +853,10 @@ interface AgentJobQueue {
 }
 declare function createAgentJobQueue(options: CreateAgentJobQueueOptions): AgentJobQueue;
 
-/** The three job ids one run's chain addresses, whether or not any of them exists. */
+/** The job ids one run's chain addresses, whether or not any of them exists. */
 interface ChainJobIds {
     readonly analyzeRun: JobId;
     readonly curateMemory: JobId;
-    readonly proposeImprovements: JobId;
 }
 /**
  * Every id the chain for `runId` would carry, from `runId` and the id source alone.
@@ -1769,31 +865,10 @@ interface ChainJobIds {
  * — because they ARE the same keys: this function predicts what that function will ask for.
  * If the two ever disagree, the projection addresses rows that exist under other ids, which
  * is the failure the shared derivation exists to make impossible.
- *
- * The third id is addressed from the SECOND, not from the run: chaining is transitive and each
- * key is built from its own predecessor, so a chain whose head id source changed moves all
- * three together rather than leaving the tail addressing a row nobody minted (422 D-13). It is
- * deliberately not keyed by candidate: candidates are discovered by the fold and a chain whose
- * identity depended on them could not be predicted before the fold ran.
  */
 declare function chainJobIdsForRun(runId: string, idSource: JobIdSource): ChainJobIds;
 
-/**
- * How an op returns its result (D-08).
- *
- * `unary` resolves ONE value, validated against the spec's `output` contract.
- * `stream` resolves a {@link FunctionStream} whose elements each honour that same
- * `output` contract — the contract describes one element, never the iterable.
- */
 type FunctionResultKind = 'unary' | 'stream';
-/**
- * A stream op's result (D-08): a typed async iterable of seq-stamped elements.
- *
- * Connection-independent by construction — every element carries its own resume token, so
- * a caller that observed token N re-invokes with that token and receives N + 1 onward.
- * Nothing about the iterable is bound to the transport that produced it, which is why
- * 386's live attach and this phase's completed-run replay are the SAME contract.
- */
 type FunctionStream<Element = unknown> = AsyncIterable<Element>;
 /**
  * One replayed run event, defined AS the element type the runner's `EventLogPort.read`
@@ -1801,17 +876,6 @@ type FunctionStream<Element = unknown> = AsyncIterable<Element>;
  * layer cannot drift out of step with the log the runner actually writes.
  */
 type ReplayedRunEvent = ReturnType<EventLogPort['read']>[number];
-/**
- * Whether the op's implementation is bound in THIS composition (D-09). A declared-but-
- * unbound op is a visible state, never a silent gap: coverage checks must treat
- * `unbound` as covered-but-unbound rather than as an absent capability.
- *
- * It is a property of a COMPOSITION, not of a spec, and since 385 (D-16) it is computed
- * that way: the field lives on {@link FunctionDeclaration} — which a registry mints from
- * the deps it was handed — and on no spec. A spec that carried a static `'bound'` would be
- * making a claim about compositions it is not part of, and the first composition that
- * omitted the implementation would report `bound` and lie. There is no literal to flip.
- */
 type FunctionBindingStatus = 'bound' | 'unbound';
 /**
  * The OPTIONAL members of {@link FunctionDeps} — the deps whose presence varies by host.
@@ -1822,88 +886,19 @@ type FunctionBindingStatus = 'bound' | 'unbound';
  * compositions can run this op" is answerable by reading two lines.
  */
 type OptionalFunctionDepKey = 'liveView' | 'runInvocation' | 'knowledgeReview' | 'postProcessing' | 'runDetail' | 'evidenceBlobs' | 'analysis' | 'recurrence' | 'quarantine' | 'chatTurn' | 'draftEvaluation' | 'authoringRead' | 'authoringScope' | 'draftShelf' | 'authoringFunnel' | 'configFiles' | 'configValidate' | 'scaffoldContent' | 'capabilityCatalog' | 'feedback' | 'feedbackReads' | 'configWrite' | 'secretMask';
-/**
- * 419 GATE3-01: the union previously had only a type-level pin, invisible to vitest.
- * Like DELTA_ORIGINS and MARKS, this runtime projection makes removal measurable.
- */
 declare const OPTIONAL_FUNCTION_DEP_KEYS: readonly ["liveView", "runInvocation", "knowledgeReview", "postProcessing", "runDetail", "evidenceBlobs", "analysis", "recurrence", "quarantine", "chatTurn", "draftEvaluation", "authoringRead", "authoringScope", "draftShelf", "authoringFunnel", "configFiles", "configValidate", "scaffoldContent", "capabilityCatalog", "feedback", "feedbackReads", "configWrite", "secretMask"];
-/**
- * The capability is declared, but no implementation is bound in THIS composition (D-09).
- *
- * Deliberately distinct from `UnknownFunctionError`: the contract exists, is listed, and
- * projects into a catalog — what is absent is the binding. A caller (or a coverage check)
- * that could not tell those two apart would read a staged capability as a hole in the API,
- * which is the silent gap `bindingStatus` exists to prevent.
- *
- * Declared here beside {@link FunctionBindingStatus} rather than beside the pipeline's
- * other refusals so an unbound op can throw it without an op → invoke → registry → op
- * import cycle; `invoke.ts` re-exports it, so the layer's refusal vocabulary still reads
- * as one set at the call site.
- */
 declare class FunctionNotBoundError extends Error {
     readonly functionId: string;
     constructor(functionId: string);
 }
-/**
- * The scalar metadata every capability carries, shared by the public view and the
- * internal spec.
- *
- * `id` is dot-namespaced `domain.verb` (D-15) over ONE canonical domain taxonomy.
- *
- * 2026-08-16 (397 D-18): this docstring used to repeat D-15's original eight domains
- * (tests · runs · memory · analysis · eval · gates · config · agent), and six later phases
- * shipped ids in domains that list does not contain — so the sentence had been false for a
- * month by the time anyone checked it. The taxonomy is now DATA rather than prose, pinned in
- * the conformance suite's `domain-list.ts` with a one-line charter apiece and censused
- * against this registry in both directions. An id in an unpinned domain is a named RED
- * there; widening the taxonomy is a reviewed one-line diff to that table. Ids are never
- * renamed to suit it — they are the shipped, locked contract, and the taxonomy serves them.
- *
- * The two CONTRACT fields are deliberately NOT here. They are the one place the view and
- * the spec must differ in kind — a projection on one, a live validator on the other — and
- * splitting them out is what makes that difference a property of the type system rather
- * than a rule someone has to remember at the seam (BL-01 / T-384-08).
- */
 interface FunctionMetadata {
     id: string;
     /** One-line human description; rendered by catalogs and `agent-qa fn --list`. */
     summary: string;
     resultKind: FunctionResultKind;
-    /** The risk descriptor of this op: listings, MCP tool annotations and the read scope read it (no gate since 432-13). */
     risk: RiskActionDescriptor;
 }
-/**
- * An INERT description of one declared contract: a JSON-Schema document, deep-frozen.
- *
- * A projection has no `parse` and no `safeParse` — there is nothing on it to run and
- * nothing on it to replace. That is the whole point. The surface-visible view used to
- * carry the live `z.ZodType`, and because ops assign the schema package's own exported
- * validators, a single write reached through a permitted `registry.list()` replaced the
- * contract vocabulary every firewalled surface imports, for the whole process. Publishing
- * a projection removes the object that write needed rather than adding a rule about it.
- *
- * D-14 already named the input contract "also the JSON-Schema projection source"; on the
- * declaration that description is now literal, and it is the shape 396's MCP tool listing
- * consumes.
- */
 type FunctionSchemaProjection = Readonly<Record<string, unknown>>;
-/**
- * What one clause's result MEANT, as the op that produced it reports (Phase 399.1, D-01/D-02/D-03).
- *
- * TWO FIELDS AND NO THIRD. `status` is the one bit a surface must not get wrong — whether the thing
- * was carried out — and `outcome` is the sentence that says which road it came in by. Anything
- * larger would be a second payload channel, and the payload has one (`results[]`).
- *
- * `not-run` IS ABSENT FROM THE STATUS SET, AND ITS ABSENCE IS THE POINT. That member describes a
- * clause the ENGINE deliberately never attempted after an earlier one failed — a fact about the
- * turn, which no op can know and none may claim. The three a classifier may return are derived from
- * the schema's own vocabulary rather than re-spelled, so a fifth receipt status cannot appear here
- * without somebody deciding whether an op may return it.
- *
- * THE `failed` MEMBER IS WHAT MAKES THIS FAIL-CLOSED POSSIBLE (D-03). A result the declared fold
- * cannot read reports `failed` with a named outcome, never `executed`: an unreadable result might be
- * a refusal, so success is the one claim a receipt must never default to.
- */
 interface ClauseVerdict {
     readonly status: Exclude<ClauseReceiptStatus, 'not-run'>;
     /**
@@ -1923,52 +918,10 @@ interface ClauseVerdict {
  * FunctionSpec} instead, which never leaves this directory.
  */
 interface FunctionDeclaration extends FunctionMetadata {
-    /**
-     * Whether THIS composition can run the op (D-09/D-16).
-     *
-     * Computed by the registry from the deps it was constructed with, never copied off a
-     * spec. A listing is therefore a fact about the host a caller is talking to: the same
-     * capability reads `bound` from a composition that supplied its implementation and
-     * `unbound` from one that did not, and `invokeFunction` refuses on exactly that answer.
-     */
     bindingStatus: FunctionBindingStatus;
-    /**
-     * This op folds its OWN result into a clause verdict (2026-08-20, Phase 399.1 D-01).
-     *
-     * PRESENCE, AS DATA — never the callable: {@link FunctionSpec.classify} stays where it is, and a
-     * function-valued field on {@link FunctionMetadata} would put something runnable back on every
-     * listing (BL-01).
-     *
-     * WHAT THE PROJECTION IS FOR, AND WHY IT IS NOT DECORATION. D-01 puts refusal knowledge in a
-     * per-op fold rather than in a chat-side rule that pattern-matches values, because a rule that
-     * can only refuse what it can NAME cannot be driven to zero by naming more things. The cost of
-     * that choice is coverage: an op that never declared a fold reports the legacy `executed` for
-     * every result it can return, silently. This boolean is what makes that countable — the census in
-     * `packages/cli` cannot reach a spec by construction, so without it the coverage question could
-     * only be answered by somebody reading forty-three op files.
-     *
-     * `true` is the only value: `false` and an absent key would be two spellings of one fact, and a
-     * present `undefined` would make a golden column read `null` for an op that simply has no fold.
-     */
     classifies?: true;
-    /**
-     * This op composes its own human-facing lines on top of the default payload render (399.1 D-04).
-     *
-     * PRESENCE, AS DATA, on the two flags above. The fold ADDS legibility and can never suppress: the
-     * default render is the complete payload and a declared fold is printed beside it, never instead
-     * of it. That is a property of the render path rather than of this flag, and the flag is here so
-     * a listing — and the golden ledger — can say which ops carry one.
-     */
     rendersResult?: true;
-    /** Inert JSON-Schema projection of the runtime input contract (D-14). */
     input: FunctionSchemaProjection;
-    /**
-     * Inert JSON-Schema projection of the runtime output contract (D-14).
-     *
-     * For a `unary` op the underlying contract describes the whole result. For a `stream`
-     * op it describes ONE element, never the iterable, and a catalog reads this projection
-     * as the element schema its transport (SSE frame, MCP notification) carries.
-     */
     output: FunctionSchemaProjection;
 }
 /**
@@ -1981,45 +934,9 @@ interface FunctionDeclaration extends FunctionMetadata {
 interface RunsReaderPort {
     /** Every completed run this project can load. Missing run storage yields `[]`. */
     list(): Promise<readonly CompletedRunHandoff[]>;
-    /**
-     * One completed run by id, or `undefined` when no such run is recorded.
-     *
-     * Absence is a RESULT, not an error: the typed refusal is the op's to throw, so the
-     * "not found" vocabulary lives in this layer rather than in every composition root.
-     * Implementations resolve the id against the runs they already enumerate — never by
-     * joining a caller-supplied string onto a filesystem path (T-384-08).
-     */
     get(runId: RunId): Promise<CompletedRunHandoff | undefined>;
-    /**
-     * Replay one run's recorded event stream, starting at `fromSeq` and in `seq` order.
-     *
-     * The exact `EventLogPort.read(fromSeq)` contract the v49 bus already replays against,
-     * lifted behind a port so this layer needs no host access. A run with no recorded
-     * events replays as an ordinary empty result — nothing was truncated, so nothing is
-     * refused. When events below `fromSeq` existed but are no longer available, the
-     * implementation rejects with the runner's `ReplayIncompleteError` carrying the lowest
-     * seq it can still serve; the op turns that into the layer's typed refusal. Serving a
-     * silently truncated prefix is the one thing an implementation may never do.
-     */
     readEvents(runId: RunId, fromSeq: number): Promise<readonly ReplayedRunEvent[]>;
-    /**
-     * Read back ONE step's persisted evidence — the substrate `knowledge.brief.why` answers
-     * from (Phase 387, KREV-02 / D-15).
-     *
-     * On the RUNS port and not on the knowledge port, and that placement is the whole honesty
-     * argument rather than filing. A step's evidence is a record of what happened during a run;
-     * the knowledge index is a record of what is true now. Answering "why did the brief say
-     * this" out of the second would answer a different question than the one asked, and the op
-     * that answers it is given no serving capability at all, so re-running retrieval is not a
-     * temptation it has to resist.
-     */
     readStepEvidence(runId: RunId, address: StepEvidenceAddress): Promise<StepEvidenceLookup>;
-    /**
-     * The target names one completed run recorded WHEN IT RAN (431 D-08), never current
-     * configuration. `unknown` when the run has no readable snapshot, including one that vanished
-     * after `list()` answered. Optional: an unbound reader leaves every run unknown, and an unknown
-     * run never matches a requested target. Implementations resolve only runs they enumerate.
-     */
     getRecordedTargets?(runId: RunId): Promise<RecordedTargets>;
 }
 /**
@@ -2063,30 +980,11 @@ type StepEvidenceLookup = {
  * writer-gated main entry is unreachable from this layer by construction.
  */
 interface KnowledgeReaderPort {
-    /**
-     * 2026-09-06, 416 D-17: gate history and the current verdict. Optional so existing
-     * implementations and fakes remain type-valid; an unbound read refuses by name.
-     */
     gateReceipts?(input: {
         candidateId: string;
     }): Promise<KnowledgeGatesListResult>;
-    /**
-     * 2026-09-07, 417 D-01: the DATA the Gate-1 bridge carries in. Optional so existing
-     * implementations and fakes stay type-valid; an unbound read refuses by name.
-     */
-    candidateInjection?(input: {
-        candidateId: string;
-    }): Promise<KnowledgeCandidateInjectionResult>;
     /** Every committed bundle, already projected to the schema-owned listing row. */
     listBundles(): Promise<readonly KnowledgeBundleSummary[]>;
-    /**
-     * The maintenance view of every record matching a closed structural filter (KREV-01).
-     *
-     * Wiring over the reader entry's own `inspectRecords`, and the return type says so: it is
-     * that function's view schema and not a paraphrase of it. KREV-01's "no new memidex code"
-     * claim survives only while that stays literally true, and the first field of a paraphrase
-     * to drift would be the one nobody looked at.
-     */
     inspectRecords(input: KnowledgeRecordsInspectInput): Promise<readonly InspectRecordView[]>;
     /** Every record change since a build ordinal — the reader entry's `diffSince`, wired. */
     diffSince(input: KnowledgeRecordsDiffInput): Promise<readonly RecordChange[]>;
@@ -2108,36 +1006,6 @@ interface KnowledgeReaderPort {
     showRecords?(input: {
         recordIds: readonly string[];
     }): Promise<readonly KnowledgeRecordShowResult[]>;
-    /**
-     * What became of the canary lines THIS run served (2026-08-29, Phase 407 · D-08).
-     *
-     * ONE ROW PER TUPLE ASKED ABOUT, in the order asked. The caller supplies the served-canary
-     * tuples it already holds from the run's own evidence — `candidateId` is the served channel-1
-     * line's id, which IS the curation candidate id — and the reader answers with the observation
-     * id each tuple's outcome event would carry, plus that outcome when a surviving attributed
-     * event exists. `outcome` ABSENT means "no attributed event survives for this tuple", which is
-     * an ordinary state (curation has not settled, or it settled and attributed nothing) and NOT
-     * an error; `observationId` is always present because it is DERIVED from the tuple —
-     * `canaryOutcomeObservationId({ candidateId, runId, testId, testIndex, stepIndex })` — rather
-     * than looked up, so a caller can name the event it is waiting for before that event exists.
-     *
-     * ON THE READER PORT AND NOT THE RUNS PORT, unlike `readStepEvidence` one interface up: the
-     * SERVING half of a canary (the marker) is a fact about the run and is read from its evidence,
-     * but the ATTRIBUTED half is a fact about the committed knowledge store's outcomes log. Asking
-     * the runs port for it would be asking a record of what happened for a record of what is true.
-     *
-     * OPTIONAL, so every existing port implementation and every test fake stays type-valid. The
-     * `/reader` entry implements it in 407-04 and agent-local binds it there; until then a caller
-     * sees `undefined` and renders the honest not-yet-attributed state rather than a wrong badge.
-     *
-     * THE ANSWER CARRIES ITS OWN PARTIALITY (407-19, REVIEW WR-03). `skippedBundles` is the walk's
-     * count of bundles it could not load — corrupt, truncated, or failing the integrity check that
-     * catches tampering. `> 0` means the answer is PARTIAL, and a caller must not render an absent
-     * `outcome` as a positive `not attributed`: on a partial walk that absence means "not found in
-     * the part of the store I could read", which is a different sentence. The count rides HERE, on
-     * the read that degraded, rather than being inferred from a sibling read failing on the same
-     * file — an inference that does not survive the two reads seeing different stores.
-     */
     canaryAttributions?(input: {
         runId: string;
         tuples: readonly {
@@ -2157,45 +1025,9 @@ interface KnowledgeReaderPort {
         readonly skippedBundles: number;
     }>;
 }
-/**
- * Injected WRITE capability over knowledge review — accept, reject and forget (Phase 387,
- * KREV-01 / D-17, declared here and implemented in 387-08; direct since 432-12).
- *
- * A SEPARATE port from {@link KnowledgeReaderPort}, and separate is the point. Widening the
- * reader with a write member would have handed a write path to every composition that only
- * ever wanted to list bundles — including the read-only surfaces the physically-separate
- * reader entry exists to keep write-free — and no lint could have told the two apart
- * afterwards, because they would have been one type. The split is what keeps "this host can
- * read knowledge" and "this host can change it" two different, separately answerable
- * questions.
- *
- * OPTIONAL on {@link FunctionDeps} and joined to {@link OptionalFunctionDepKey} for the same
- * reason `runInvocation` is: a host that cannot mutate knowledge — a listing registry, a
- * read-only surface — must report that as a VISIBLE `unbound` on the verbs by name, not as a call
- * that fails somewhere far away.
- *
- * 2026-09-30, 432-12 (D-04/D-05/D-09): `change` applies an explicit accept, reject or forget in the
- * call, through the explicit writer, in every execution context, under the writer lease. It is the
- * member every change op reaches. 2026-10-01 (432-17): `propose` and `apply` are deleted with the
- * proposal inbox; old proposal files are never read again (D-22).
- */
 interface KnowledgeReviewPort {
-    /**
-     * Apply one explicit knowledge change in the call and answer what it changed (432-12).
-     *
-     * Validation, target resolution, the writer lease, delegation to a live holder, delta
-     * validation, bundle egress and every promotion gate belong to the writer behind this member.
-     * A repeated `operationId` is the same change and lands once; an absent one is minted.
-     */
     change(request: KnowledgeChangeRequest): Promise<KnowledgeChangeOutput>;
 }
-/**
- * One explicit knowledge change (432-12): the verb, the input that verb takes, and the caller's
- * stable identity for it when the caller has one.
- *
- * Discriminated so `reject`'s required reason cannot be omitted by asking for an accept. A mark is
- * not here: it changes knowledge through `runs.mark`, which owns its own identity and checkpoints.
- */
 type KnowledgeChangeRequest = ({
     readonly verb: 'accept';
     readonly input: KnowledgeAcceptInput;
@@ -2208,90 +1040,29 @@ type KnowledgeChangeRequest = ({
 }) & {
     readonly operationId?: string;
 };
-/**
- * Injected read port over the entity directory (Phase 387, ENTY-01 / D-09).
- *
- * Two verbs, and the split is the never-guess contract expressed as a type. `resolve` takes
- * anything a human or a model might say and answers with a closed three-arm union, so a
- * caller is structurally unable to receive a maybe. `get` takes an address that already
- * exists and answers with the entity or with nothing.
- *
- * Descriptor-level on purpose. The port carries FACTS about an entity and never a card,
- * which is what leaves exactly one card producer in this layer (ENTY-02): a composition
- * cannot render, because it is handed no vocabulary in which to do so.
- *
- * `get` may not mint. `resolve` sights, and sighting is what assigns a permanent address
- * (D-01); a `get` that could write would make every card render on every surface a
- * potential mutation of the one durable store this system never rebuilds.
- */
 interface EntityDirectoryPort {
     resolve(ref: string): Promise<EntityResolution>;
     get(ref: string): Promise<EntityDescriptor | undefined>;
 }
-/**
- * One post-run chain job as the chip projection needs to see it (Phase 388, D-14).
- *
- * Status and claim drive the chips; optional recorded facts drive the stage detail (423 D-12).
- * The claim remains separate from status, so running does not widen the job vocabulary.
- * Missing facts stay absent, including on older reader implementations.
- */
 interface PostProcessingJobRow extends Readonly<PostProcessingStageDetail> {
     readonly status: JobStatus;
     /** Whether a drainer holds this job right now. `false` covers queued and terminal alike. */
     readonly claimed: boolean;
 }
-/**
- * What one run's post-run chain has durably recorded, by member (Phase 388, D-14; narrowed to
- * the two chip stages — Phase 404, D-01, 2026-08-26).
- *
- * Every member is OPTIONAL, and each absence is a real, different situation: no analyze-run row
- * means nothing was ever enqueued for this run; no curate-memory row means the analysis has not
- * chained yet. Padding either of them with a synthetic row would erase exactly the distinction
- * the projection reads.
- *
- * 423 D-12 reports all three durable stage rows. Proposals contributes detail only;
- * the chip set remains analysis and curation.
- *
- * 2026-09-01 (Phase 409): the chain's third derived id left with the Issue-slot cleanup.
- * 2026-09-11 (Phase 422, D-13): a third derived id returns, without a third chip.
- */
 interface PostProcessingChainState {
     readonly analyzeRun?: PostProcessingJobRow;
     readonly curateMemory?: PostProcessingJobRow;
-    readonly proposeImprovements?: PostProcessingJobRow;
-    /** Completed curation facts, available before the proposals stage reaches terminal. */
+    /** Completed curation facts, available before the chain terminal is written. */
     readonly curationSnapshot?: CurationSnapshot;
-    /** The chain-terminal record, once the terminal transaction wrote it (D-09). */
     readonly notification?: RunNotification;
 }
-/**
- * Injected read port over the durable post-run chain state (Phase 388, D-14).
- *
- * OPTIONAL on {@link FunctionDeps}, so a host with no queue storage lists `runs.postProcessing`
- * as `unbound` BY NAME rather than answering a confident all-pending about a chain it has no
- * way to see.
- *
- * The port carries the host's `idSource` rather than resolving ids itself, and that placement
- * is the load-bearing part. Chain identity is DERIVED (RESEARCH Pattern 2), and it must be
- * derived through the same source the host's queue enqueued with — a reader that owned its own
- * derivation would address rows under other ids the moment a composition configured a different
- * source, and would report `pending` about a chain that had already finished. So the function
- * layer derives, once, through `chainJobIdsForRun`, and the port only reads what it is handed.
- *
- * Reads are fence-free by design: reading claims no authority, so a status query neither adopts
- * an epoch nor competes with the drainer that holds one.
- */
 interface PostProcessingReaderPort {
     /** The id source THIS host's queue derives job ids with. */
     readonly idSource: JobIdSource;
     /**
      * Durable state for the ids given, or `undefined` when this project holds no queue database
      * at all. Chain identity is still the job-kind layer's to derive, and this port only reads
-     * what it is handed: all three ids, with the proposals row used only for detail (423 D-12).
-     * It may not derive an id of its own.
-     *
-     * 2026-09-01 (Phase 409): the width dropped from three to two.
-     * 2026-09-11 (Phase 422, D-13): three again, and no longer equal to the state's member count.
+     * what it is handed, and it may not derive an id of its own.
      *
      * `undefined` is a distinct answer from an empty state and both are honest: the first says
      * nothing has ever been enqueued here, the second says this chain's rows are not among the
@@ -2300,64 +1071,13 @@ interface PostProcessingReaderPort {
      */
     readChain(ids: ChainJobIds, runId: string): Promise<PostProcessingChainState | undefined>;
 }
-/**
- * Injected read port over ONE run's durable dashboard projection (Phase 405, D-03).
- *
- * `packages/agent` is `storageNeutral`: no host builtin is importable here, so every row arrives
- * through this port, built at the composition root over the concrete dashboard SQLite database.
- * The port answers ROWS — members, steps, sub-actions — and nothing derived; the D-06 token sum is
- * the op's, computed once in the layer that owns the contract rather than once per host that
- * happens to hold a database.
- *
- * ABSENCE IS A RESULT, NEVER A PATH JOIN ON CALLER INPUT (the `RunsReaderPort.get` law, T-384-08).
- * A run id that names nothing answers `undefined`, and turning that into the layer's typed refusal
- * is `runs.detail`'s job — so the "not found" vocabulary lives here in one place rather than in
- * every composition root. An implementation resolves the id against the rows it already
- * enumerates; joining a caller-supplied string onto a filesystem path is the one thing it may
- * never do.
- *
- * OPTIONAL on {@link FunctionDeps} for the reason `postProcessing` is: a host with no dashboard
- * database genuinely cannot say what a run's steps were, and the alternative to reporting that by
- * name is answering an empty projection about a run it has never been able to see — a wrong answer
- * wearing a correct one's clothes.
- */
 interface RunDetailReaderPort {
     /** One run's projected rows, or `undefined` when the runs database holds no such run or does not exist yet. */
     read(runId: RunId): Promise<RunDetailRows | undefined>;
-    /**
-     * 2026-10-18 (444-12, D-14): the run's own row status, or `undefined` when no row is recorded.
-     * Optional: a host without it derives no `no-verdict` fact, because absence is not a status.
-     */
     readRecord?(runId: RunId): Promise<{
         status: string;
     } | undefined>;
 }
-/**
- * Injected read port over ONE run's content-addressed evidence blobs (Phase 405, D-12/D-13).
- *
- * `packages/agent` is `storageNeutral`: no filesystem is importable here, so the bytes arrive
- * through this port, built at the composition root over the SAME `FsEvidenceArtifactStore` the
- * runner wrote them with. The port answers BYTES and nothing derived — the content-type sniff is
- * `runs.artifact`'s, computed once in the layer that owns the contract rather than once per host
- * that happens to hold a runtime root.
- *
- * ABSENCE IS A RESULT, AND IT IS TWO RESULTS (D-15). See {@link EvidenceBlobLookup}: the concrete
- * store collapses "no such run" and "no such blob" into one `undefined`, and an implementation of
- * this port is where that distinction is recovered — because above it the two are different things
- * a page has to render. Turning either arm into a typed refusal is the op's job, so the "not
- * found" vocabulary lives in one place rather than in every composition root.
- *
- * THE PORT NEVER JOINS CALLER INPUT ONTO A PATH (the `RunsReaderPort.get` law, T-384-08 /
- * T-405-14). Containment is the STORE's own rule — `slugBranch` over the runId and a
- * 64-lowercase-hex check over the sha, both inside `FsEvidenceArtifactStore` — and an
- * implementation that assembled a path itself would be a second containment rule, free to be
- * weaker than the one the runner writes through.
- *
- * OPTIONAL on {@link FunctionDeps} for the reason `postProcessing` is, and for a sharper one: the
- * alternative was widening the REQUIRED {@link RunsReaderPort} with a blob verb, which every
- * daemon, MCP and test implementer of that port would then have to satisfy with storage most of
- * them do not have.
- */
 interface EvidenceBlobReaderPort {
     /** One blob's bytes, or which KIND of absence this host is reporting. */
     read(runId: RunId, sha: string): Promise<EvidenceBlobLookup>;
@@ -2368,66 +1088,15 @@ interface EvidenceBlobReaderPort {
         status: 'unknown_run' | 'blob_absent';
     }>;
     readRange?(runId: RunId, sha: string, start: number, end: number): Promise<EvidenceBlobLookup>;
-    /**
-     * The same question asked as a STAT — are the bytes still there — for read-time presence
-     * annotation on the durable reads (Phase 406, D-17).
-     *
-     * OPTIONAL SO THAT EVERY EXISTING IMPLEMENTATION AND FAKE KEEPS COMPILING, and for the sharper
-     * reason that absence here is a real host condition rather than an oversight: a host that cannot
-     * cheaply stat its blobs is not lying about anything, and an op that finds this member missing
-     * OMITS presence rather than reporting refs it never looked at as absent. A claimed absence is
-     * the one answer this field must never be able to give by accident, because it renders honest
-     * evidence as `evidence-incomplete`.
-     *
-     * IT ANSWERS THE SAME THREE WORDS `read` DOES, so the two cannot disagree about WHICH absence a
-     * ref is in — the read is this answer plus the bytes, never a second rule.
-     */
     has?(runId: RunId, sha: string): Promise<EvidenceBlobPresence>;
 }
-/**
- * Injected read port over a run's persisted analysis artifact (Phase 389, D-10/D-11).
- *
- * `analysis.json` is the analyze-run job's own receipt; the only legal reader routes its
- * bytes through `guardRunAnalysisArtifact` (the version guard), and an implementation of
- * this port does exactly that at the composition root — the op receives a guarded document
- * or a typed absence, never raw bytes.
- *
- * `undefined` is an ANSWER, not an error: a run whose analysis never ran (budget spent,
- * daemon down, chain still in flight) has no artifact, and the ops answer it through the
- * D-10 accessor's handoff floor. That is why `runs.get` treats an UNBOUND port the same
- * way — artifact-absent — while `analysis.get` refuses by name: a listing that cannot see
- * artifacts still lists truthfully off the floor, but a caller asking for THE analysis of
- * a run must be told this host cannot serve one.
- */
 interface AnalysisArtifactReaderPort {
     /** The guarded artifact for one run, or `undefined` when none is on disk. */
     getArtifact(runId: string): RunAnalysisArtifact | undefined;
 }
-/**
- * Injected read port over the resolved project configuration.
- *
- * The port's name says what its security contract is: it yields a config whose
- * secret-bearing values were dropped while the DTO was CONSTRUCTED. There is deliberately
- * no unmasked variant on this port — a capability that could ask for one would make the
- * masking optional, and optional masking is not masking (T-384-07).
- */
 interface ConfigReaderPort {
     getMasked(): Promise<MaskedResolvedConfig>;
 }
-/**
- * Injected capability that STARTS a run (D-16, Phase 385).
- *
- * Its one verb resolves the identity of the run it started and nothing else. That narrowness
- * is the point: the acknowledgment a caller receives is not assembled from what this port
- * SAYS happened, it is read back off the run's own durable record through
- * {@link RunsReaderPort} — the same port `runs.get` answers from. A host that returned an id
- * without running anything therefore fails at the join rather than at a promise nobody can
- * check.
- *
- * Owning the process model is what makes this a port rather than shared code (the plan-08
- * dissection rule): a terminal host runs a suite one way, a daemon another, and neither
- * would call the other's orchestration as written.
- */
 interface RunInvocationPort {
     /**
      * Start a run for this request and resolve when the run has been recorded.
@@ -2441,51 +1110,6 @@ interface RunInvocationPort {
 interface StartedRun {
     readonly runId: RunId;
 }
-/**
- * The injected-dependency record every op implementation receives. Ops are pure
- * functions of (validated input, deps) — they never reach for a host API.
- *
- * The four READ ports are required and non-partial on purpose: a composition that omits one
- * fails to typecheck. Phase 387 adds `entities` as the fourth, and it joins as REQUIRED
- * rather than optional deliberately — every host that can list a capability can also resolve
- * an address, so a host that omitted it would not be reporting a real absence, it would be
- * reporting that somebody forgot. That is precisely the state the required/optional split
- * exists to distinguish, and widening the optional side to cover a forgetting would have
- * made `unbound` mean two different things.
- *
- * The OPTIONAL members' optionality is not a relaxation of that discipline but the mechanism
- * behind it. Not every host can start a run — a read-only surface, a registry built for a
- * listing, 386's daemon before it wires its own executor — and D-09 requires that state to be
- * VISIBLE rather than a call that fails somewhere far away. Omitting `runInvocation` makes
- * `runs.start` list as `unbound` and refuse by name; supplying it makes the same capability
- * bound. Any further optional member must join {@link OptionalFunctionDepKey} so the same
- * reporting applies to it.
- *
- * `knowledgeReview` (387, KREV-01) is the second, and it is the one that makes the required/
- * optional split earn its keep on the WRITE side: the ability to read committed knowledge and
- * the ability to change it are separate powers, so they are separate members. A host that
- * supplies only the reader lists the mutating verbs as `unbound` by name — which is a true
- * statement about that host, and is exactly what widening the reader port with a write member
- * would have made unsayable.
- */
-/**
- * The live-view seam `runs.liveurl` mints through (403 D-03).
- *
- * OPTIONAL, and its absence is a GENUINE HOST FACT rather than a degraded mode: a CLI run in a
- * terminal serves no origin, so there is no URL it could honestly hand back. A host that binds it
- * supplies the per-process signer, the origin it is actually listening on, and a read of the live
- * run registry — never a token, and never a parse.
- *
- * `capabilityOf` answers `undefined` for a run this host has no live session for (the op turns
- * that into `unknown_run`) and a `LiveStreamDeclaration` — possibly `{ kind: 'none' }` — otherwise.
- * `onMinted` observes every minted token value. 2026-10-14 (441-16, D-01): no shipped host binds it
- * (a minted token is not a declared secret); tests use it to capture what the op really minted.
- *
- * `editorCapabilityOf` is the editor subject's read (428 D-07), through which `editor.liveurl`
- * mints. ABSENT means this host serves no live editor — the standalone MCP host and the MCP App
- * host never bind it, and the op refuses by name. `undefined` means no such live editor session.
- * It is a separate lookup from `capabilityOf` so an editor session can never be addressed as a run.
- */
 interface LiveViewPort {
     signer: LiveUrlSigner;
     origin(): string | undefined;
@@ -2500,230 +1124,30 @@ interface FunctionDeps {
     config: ConfigReaderPort;
     entities: EntityDirectoryPort;
     runInvocation?: RunInvocationPort;
-    /**
-     * 403 D-03: the live-view mint seam. See {@link LiveViewPort} — absent means this host has no
-     * served origin, and `runs.liveurl` refuses by name rather than minting a link to nowhere.
-     */
     liveView?: LiveViewPort;
     knowledgeReview?: KnowledgeReviewPort;
-    /**
-     * 388 D-14: the durable post-run chain read. The third optional member, and it joins for the
-     * reason the other two did rather than by analogy — a host with no queue storage genuinely
-     * cannot answer "what became of that run's analysis", and the alternative to reporting that
-     * by name is answering `pending` about a chain it has never been able to see, which is a
-     * wrong answer wearing a correct one's clothes.
-     */
     postProcessing?: PostProcessingReaderPort;
-    /**
-     * 405 D-03: the durable run-detail projection read. See {@link RunDetailReaderPort} — absent
-     * means this host owns no dashboard projection database, and `runs.detail` refuses BY NAME
-     * rather than answering an empty run about a projection it cannot observe. The CLI host binds it
-     * over the configured or default runs database path whenever its config parses (a read before
-     * that file exists answers not recorded in the runs database); the dashboard passes its own handle.
-     */
     runDetail?: RunDetailReaderPort;
-    /**
-     * 405 D-12/D-13: the run-scoped evidence-blob read. See {@link EvidenceBlobReaderPort} — absent
-     * means this host owns no runtime root, and `runs.artifact` refuses BY NAME rather than
-     * answering `blob_absent` about every artifact in the product, which would read to an operator
-     * as storage loss. Bound on every LOCAL host, which is exactly the set that has run directories.
-     */
     evidenceBlobs?: EvidenceBlobReaderPort;
-    /**
-     * 389 D-10/D-11: the analysis-artifact read. `analysis.get` binds through it and refuses
-     * by name where it is absent; `runs.get` reads it opportunistically and treats an unbound
-     * port as artifact-absent (the floor), because the cheapest read must stay cheap and a
-     * listing off the deterministic floor is honest, not degraded. Bound in plan 06's
-     * composition root over the run-directory `analysis.json` + version guard.
-     */
     analysis?: AnalysisArtifactReaderPort;
-    /**
-     * 389 D-08: the live recurrence seam the one renderer joins through. OPTIONAL because a
-     * host without the knowledge index genuinely has no history to answer with — and the
-     * renderer's contract turns that absence into the explicit no-history clause rather than
-     * a refusal, so `analysis.get` stays bound wherever `analysis` is. Bound in plan 06 to
-     * v51's run-outcome projection; 390 rebinds the SAME seam to its fingerprint window.
-     */
     recurrence?: RecurrenceProvider;
-    /**
-     * 390 D-12/D-13: the committed quarantine ledger's three verbs — list, release, add.
-     *
-     * OPTIONAL for the reason `knowledgeReview` is, and not by analogy: a host with no knowledge
-     * root genuinely cannot enumerate quarantine state, and the alternative to saying so by name
-     * is answering an empty list about a ledger it has never been able to read — a wrong answer
-     * wearing a correct one's clothes. On the write side the stakes are higher still: an unbound
-     * `add` that no-opped would report a test as quarantined while it kept failing every build.
-     *
-     * ONE port for all three verbs rather than a reader/writer split, because the read/write
-     * asymmetry is already stated on each op's risk descriptor — `quarantine.list` declares a
-     * read-only descriptor, `release` and `add` declare `readOnly: false` — so a second port would
-     * restate at the composition root a distinction the descriptors already carry. 2026-10-02
-     * (432-39, D-12): no op declares a scope and no gate enforces the split at a call; it lives only
-     * on the descriptors. The port TYPE is minted in schema, so knowledge-local can implement it
-     * without depending on the function layer.
-     */
     quarantine?: QuarantineOperationsPort;
-    /**
-     * 419 GATE3-01: the mark port — assembled by the cli host over eval-local + the review
-     * port; absent on hosts that cannot freeze gold.
-     */
+    /** The mark port; absent, `runs.mark` is unbound by name and `runs.detail` lists no marks. */
     feedback?: FeedbackPort;
-    /**
-     * 423 D-19: read-only feedback observations. Separate from `feedback` so a host can serve
-     * history without mark authority; absent means `runs.marks.history` is unbound by name.
-     * 423 D-16: the same binding carries `preview`, runs.mark's plan for an exact input with no
-     * write; a binding without that verb leaves `runs.mark.preview` unbound by name.
-     */
     feedbackReads?: FeedbackReadsPort;
-    /**
-     * 392 D-24: the assembled chat turn engine, behind which `agent.ask` runs.
-     *
-     * OPTIONAL for the reason its neighbours are, and the honest absence matters more here than
-     * anywhere else in this record: a host with no engine — a remote read surface, a daemon before
-     * a chat host exists — genuinely cannot run a turn, and the alternative to reporting that by
-     * name is answering an EMPTY turn. A person told "I understood you and did nothing" stops
-     * asking, which is the same failure the unbound proposals inbox was reasoned about avoiding.
-     *
-     * The port is a single verb by design. Anything wider — a session lister, a history reader —
-     * would be reach the turn entry does not need and would give a surface holding this dep a way
-     * into session state without a registered op declaring it.
-     */
     chatTurn?: ChatTurnPort;
-    /**
-     * 393 D-01 / D-15: the two host halves one draft evaluation needs — resolve a caller's path to a
-     * parsed draft, and assemble the ports the four gates run against.
-     *
-     * ONE BUNDLED CAPABILITY rather than five separate deps, on the `runInvocation` precedent. The
-     * receipts store, the suite fingerprint index, the text corpus and the run pair are not
-     * independently bindable: an index scoped to a different product than the runs were taken under
-     * would compare a draft against another project's suite, and a host that could supply three of
-     * the five would list this op `bound` and then fail somewhere far from the composition that
-     * forgot one. Bundling makes "can this host verify a draft" a single fact.
-     *
-     * OPTIONAL for the reason `runInvocation` is, and here it says two things at once: a host that
-     * cannot PARSE a test file and a host that cannot START a run are both hosts that cannot verify
-     * a draft, and `composeLocalAgent()` binds this only when it has both.
-     *
-     * WHY RESOLUTION IS A SEPARATE VERB FROM EVALUATION. `packages/agent` is `storageNeutral`: it
-     * cannot stat a path, read a file, or know where the workspace ends. So the three refusals that
-     * need a filesystem are ANSWERED by the host and NAMED by the op — `resolveDraft` returns a
-     * typed outcome and never throws a host error through the layer, and
-     * `functions/ops/authoring-verify-draft.ts` maps each arm onto its own caller-facing class. The
-     * alternative — a single `evaluate(draftPath)` — would have put the refusal vocabulary in
-     * whichever package happened to own the syscall, one layer below where a caller catches it.
-     */
     draftEvaluation?: DraftEvaluationPort;
-    /**
-     * 394 D-01 / WTST-01: the authoring loop's read half — the brief, and the authored suite as
-     * text (stages 1-2).
-     *
-     * OPTIONAL for the reason `draftEvaluation` is, and the honest absence is load-bearing here in
-     * a way it is nowhere else in this record. A host with no knowledge index cannot serve an
-     * authoring brief, and the alternative to saying so by name is compiling a test from an EMPTY
-     * brief — which produces a plausible draft, authored against nothing this project knows, and
-     * says so nowhere. That is a wrong answer wearing a correct one's clothes, and it is wearing
-     * them into a file the user is asked to commit.
-     */
     authoringRead?: AuthoringReadPortLike;
-    /**
-     * 394-26 / WTST-01: which scope this project authors for, when the caller named none.
-     *
-     * OPTIONAL and consulted ONLY on absence. `authoring.draft.write`'s `scope` is optional at the
-     * registry (the `runs.start` law), so an input carrying just an intent has to be resolved
-     * before the loop runs — and the resolution reads the config and the workspace, which
-     * `packages/agent` cannot do. A composition that binds the loop's other halves and forgets this
-     * one refuses BY NAME on a scope-less call rather than authoring against a default: a guessed
-     * product is a draft written for the wrong application, which is the one failure mode a silent
-     * fallback here would produce.
-     */
     authoringScope?: AuthoringScopePortLike;
-    /**
-     * 394 D-01 / WTST-01: the authoring loop's compile half — the model, and the draft shelf
-     * (stage 3).
-     *
-     * Bound with `authoringRead` or not at all: `composeLocalAgent()` supplies the pair, because a
-     * host that can read but not write is not a degraded author, it is a host that must say
-     * `unbound` by name. `authoring.draft.write` names THIS key in `boundThrough` — it is the half
-     * that makes the op mutating — and refuses on either half's absence at the invoke, so an
-     * in-layer caller holding the spec directly gets the same named error.
-     */
     draftShelf?: DraftShelfPortLike;
-    /**
-     * 394-07 D-12 / WTST-05: the honesty funnel's reads — the receipts store and (optionally within
-     * the bundle) the outcome projection and quarantine ledger D-14 consults. 2026-10-01 (432-17): the
-     * proposals inbox the `accepted` stage read is deleted; 2026-10-02 (quick 261002-ctr) that stage
-     * is `writeEligible`, read off the receipts (see `projectAuthoringFunnel`).
-     *
-     * OPTIONAL, and the stakes sit on the READ side. A host with no agent-qa runtime root cannot list draft receipts, and the alternative to
-     * saying so by name is answering an all-zero funnel — which does not merely under-report, it
-     * reports a loop that filtered everything, the one reading of a zero funnel that FLATTERS the
-     * loop this measurement exists to keep honest.
-     */
     authoringFunnel?: AuthoringFunnelPortLike;
-    /**
-     * 395 D-03/D-17 · CFGM-01/04: the pinned config file SET as RAW BYTES, plus the comment-preserving
-     * field edit over them.
-     *
-     * DELIBERATELY NOT A WIDENING OF {@link ConfigReaderPort}, which is masked-only by contract and
-     * must stay so — a capability that could ask it for unmasked values would make masking optional,
-     * and optional masking is not masking. This port answers a different question: what bytes are
-     * COMMITTED in the person's repository. Those carry no resolved secrets, because D-11 makes
-     * committed config refs-only by law.
-     *
-     * The EDIT rides the same port as the read because both are host facts. `yaml`'s Document API is
-     * an external dependency `packages/agent`'s ownership contract does not admit, and admitting one
-     * to bring the edit in-layer would widen a boundary rather than respect it.
-     */
     configFiles?: ConfigFilesPortLike;
-    /**
-     * 395 CFGM-01: whole-config validation, which runs BEFORE a change is written.
-     *
-     * A PORT because `AgentQaConfigSchema` and `validateProject` live in `@vostride/agent-qa-core`
-     * and this package does not depend on it — `validate:arch` reds that edge with no legal repair.
-     * The capability is declared here and bound in `cli`.
-     */
     configValidate?: ConfigValidatePortLike;
-    /**
-     * 395-08 D-04 · CFGM-05: the shared scaffold CONTENT, rendered by the host that owns it.
-     *
-     * THE ONE DEP `config.project.scaffold` HAS AND THE OTHER FIVE CHANGE OPS DO NOT. D-04's claim
-     * is that `agent-qa init` and the scaffold change write one substance; that substance lives
-     * beside `init`'s filesystem machinery in `packages/cli`, which this package may not import. Its
-     * absence makes exactly one op unavailable, and it says so by name.
-     */
     scaffoldContent?: ConfigScaffoldContentPortLike;
-    /**
-     * 2026-09-30, 432-07 D-05/D-07: the direct config writer. Field changes merge in the config
-     * path's shared write turn and whole files publish over the digest they were built from. No
-     * proposal is filed and no git process runs.
-     */
     configWrite?: ConfigWritePortLike;
-    /**
-     * 2026-08-17 (398 D-09/D-11 · XPLN-02): the four host halves one `explain` needs — the committed
-     * catalog as data, the model's citation over it, and the two coverage hooks.
-     *
-     * ONE PORT AND NOT FOUR DEPS, on the `draftEvaluation` bundle's stated reasoning: a host that
-     * could load the catalog but not cite over it would list `agent.explain` as `bound` and then
-     * answer every question with a ghost citation, which abstains — safe, and useless, and reported
-     * nowhere. "Can this host explain itself" is one fact.
-     *
-     * OPTIONAL for the reason `analysis` is, and the honest absence is unusually load-bearing here.
-     * `packages/agent` is storageNeutral: it cannot read the committed artifact, so a composition
-     * that omitted the port and got a degraded answer would be answering FROM MODEL MEMORY, which is
-     * the single behaviour XPLN-02 exists to make impossible. The op refuses BY NAME instead.
-     */
     capabilityCatalog?: CapabilityCatalogPort;
-    /** 441 D-06: the host's declared-secret mask for projected run text; absent or throwing, run reads fail closed. */
     readonly secretMask?: MaskFn;
 }
-/**
- * What a host can tell the layer about a caller-supplied draft path (393, T-393-01).
- *
- * A discriminated union rather than `ParsedDraftLike | undefined`: "there is no file there", "that
- * is a directory", "that is outside this workspace" and "that file is not a test" are four
- * different things to tell a person, and collapsing them into an absence would make the op answer
- * all four with one message. Every arm but `parsed` becomes a NAMED error at the invoke.
- */
 type DraftResolution = {
     readonly kind: 'parsed';
     readonly draft: ParsedDraftLike;
@@ -2737,26 +1161,10 @@ type DraftResolution = {
     readonly kind: 'unparsable';
     readonly reason: string;
 };
-/**
- * The capability `authoring.draft.verify` binds through (393 D-01).
- *
- * `openEvaluation` takes the resolved draft because two of the four ports depend on WHICH draft is
- * being evaluated: the suite comparison must exclude the draft's own identity from both of gate
- * 3's lanes, or a draft that already lives in the authored suite would be measured against itself
- * and could never be shown to add value. It is a separate call from `resolveDraft` so a refused
- * path costs no database handle and no suite walk.
- */
 interface DraftEvaluationPort {
     resolveDraft(draftPath: string): Promise<DraftResolution>;
     openEvaluation(draft: ParsedDraftLike): Promise<EvaluateDraftPorts>;
 }
-/**
- * The one verb `agent.ask` binds through (392 D-24).
- *
- * Typed against the SCHEMA contracts rather than against the engine's own types, which is what
- * lets the composition root hand this layer an engine without the function layer depending on how
- * a turn is assembled — and what lets 396's MCP projection describe the same shape.
- */
 interface ChatTurnPort {
     runTurn(input: AgentAskInput): Promise<AgentAskResult>;
 }
@@ -2771,19 +1179,6 @@ interface CreateFunctionRegistryOptions {
     deps: FunctionDeps;
 }
 interface FunctionRegistry {
-    /**
-     * Declaration views of every registered op, sorted lexicographically by id.
-     *
-     * 2026-10-01 (432-20, D-12): the same list for every caller. The safe-mode filter that hid ops
-     * whose scopes exceeded `read` is deleted with the scopes themselves, so the caller argument is
-     * not read. 2026-10-02 (432-39): the caller contract is narrowed to `surface`/`origin`.
-     *
-     * KEPT, DATED 2026-10-02 (432-42 census decision): the argument stays and stays unread. Removing
-     * it changes no behaviour and touches every listing call site in the workspace (well over a
-     * hundred, most of them other plans' fixtures), so the churn buys nothing a reader can observe.
-     * It is not a permission seam: C432-TOKENLESS-CATALOG and C432-ALL-OPS-AVAILABLE pin that every
-     * caller lists the same set, so a filter returning here reds by name.
-     */
     list(caller: FunctionCaller): readonly FunctionDeclaration[];
 }
 /** Build the registry of built-in capabilities over composition-supplied dependencies. */
@@ -2811,26 +1206,11 @@ declare class UnknownFunctionError extends Error {
     readonly functionId: string;
     constructor(functionId: string);
 }
-/** The supplied input failed the op's declared input contract (D-14). */
 declare class FunctionInputError extends Error {
     readonly functionId: string;
     readonly issues: string;
     constructor(functionId: string, issues: string);
 }
-/**
- * Run one registered capability on behalf of one caller.
- *
- * Order is load-bearing and asserted by tests:
- *   1. resolve the spec        — unknown id fails before any dependency is touched
- *   2. validate the input      — malformed input never reaches an implementation
- *   3. binding check           — a declared-but-unbound op refuses by name
- *   4. dispatch                — the only place a spec implementation ever runs
- *   5. validate the output     — unary results honour their declared contract
- *
- * Stream ops (D-08) run through the SAME steps. Nothing between the refusals and dispatch asks
- * anybody anything (432-13), and nothing reads who is calling (432-20): `caller` is accepted so
- * every door keeps one call shape, and the record it carries is presentation data only.
- */
 declare function invokeFunction(registry: FunctionRegistry, functionId: string, input: unknown, _caller: FunctionCaller): Promise<unknown>;
 
 /**
@@ -2882,14 +1262,6 @@ declare class RunNotRecordedError extends Error {
 }
 
 declare const RUNS_EVENTS_FUNCTION_ID = "runs.events";
-/**
- * The requested resume point is below the lowest seq the log can still serve.
- *
- * A caller-facing refusal, and the ONE alternative to silently serving a gap: the caller
- * learns the exact seq replay can restart at, so it can decide whether to accept the loss
- * or re-read the run in full. `earliestAvailableSeq` is the documented resume floor the
- * v49 bus reports, carried across the layer boundary unchanged.
- */
 declare class StreamReplayFloorError extends Error {
     readonly runId: string;
     readonly requestedSeq: number;
@@ -2899,39 +1271,17 @@ declare class StreamReplayFloorError extends Error {
 
 /** The token's format marker. A FIXED prefix, deliberately — there is no algorithm negotiation. */
 declare const LIVE_URL_TOKEN_VERSION = "v2";
-/** How long a minted `liveUrl` stays valid (D-02). Short by design; the socket renews in place. */
 declare const LIVE_URL_TTL_MS: number;
-/** The served embed page's path prefix (D-06, ratified). Bare — no `/api/` for a host to allowlist. */
 declare const LIVE_EMBED_PATH_PREFIX = "/live/";
 /** base64url-encode an ASCII string. The claims body is JSON of integers + ids, so ASCII holds. */
 declare function encodeBase64Url(text: string): string;
 /** base64url-decode to an ASCII string, or `undefined` when the input is not base64url at all. */
 declare function decodeBase64Url(text: string): string | undefined;
-/**
- * Mint a token for `claims`. The ONLY producer of `liveUrl` tokens in the system — `runs.liveurl`
- * is its only caller, which is what makes the minted-token secret store complete (D-04, Q4(b)).
- */
 declare function mintLiveUrlToken(signer: LiveUrlSigner, claims: LiveUrlClaims): string;
-/**
- * Validate a token against the subject it was presented for: a run by its id, or an editor session
- * by its id. A signed subject of another kind, or of the same kind with another id, is
- * `scope_mismatch` (428 D-07).
- *
- * THE SIGNATURE IS CHECKED BEFORE THE BODY IS PARSED (T-403-01). A validator that parses first
- * reports `malformed` for an attacker-authored body and `bad_signature` only for a well-formed
- * forgery — which hands the attacker a free oracle for "did my claims body parse". Here, anything
- * that survives the shape check is signature-checked immediately, so an unsigned body is
- * `bad_signature` no matter how it is spelled inside.
- */
 declare function validateLiveUrlToken(signer: LiveUrlSigner, token: string, expect: {
     subject: LiveViewSubjectRef;
     now: number;
 }): LiveUrlVerdict;
-/**
- * Compose the viewer-facing URL. The token rides the FRAGMENT and nothing else (D-04): a fragment
- * is never sent to the server on any request, never lands in an access log, and never appears in a
- * `Referer` — the three durable channels a query parameter would leak into by default.
- */
 declare function liveUrlOf(origin: string, runId: string, token: string): string;
 
 declare const RUNS_LIVE_URL_FUNCTION_ID = "runs.liveurl";
@@ -2962,15 +1312,6 @@ declare class UnknownLiveEditorSessionError extends Error {
     constructor(sessionId: string);
 }
 
-/**
- * No entity is addressed by this reference.
- *
- * A typed refusal rather than an `undefined` result, on the `RunNotFoundError` precedent: the
- * absence is the ANSWER to a caller who asked for one specific thing, and a surface needs to
- * be able to phrase it. Note what it does not mean — a permanently minted address whose
- * entity has since been tombstoned still RESOLVES (D-04), to a card whose status says so.
- * This error is for an address nothing ever minted.
- */
 declare class EntityNotFoundError extends Error {
     readonly ref: string;
     constructor(ref: string);
@@ -2996,23 +1337,8 @@ declare class AmbiguousStepAddressError extends Error {
     constructor(runId: string, stepIndex: number, testIds: readonly string[]);
 }
 
-/**
- * All lowercase, and that is a measurement rather than a taste.
- *
- * D-15's id taxonomy is pinned by `parity-coverage.test.ts` as `/^[a-z]+(?:\.[a-z]+)+$/`, so a
- * camelCased verb segment is not a spelling this catalogue admits. The shape follows
- * `runs.events` — a domain and a noun — because what this op returns is a STATE and not an
- * action. The exported constant is what plan 04 and every later surface name; the literal
- * appears here once.
- */
 declare const RUNS_POST_PROCESSING_FUNCTION_ID = "runs.postprocessing";
 
-/**
- * All lowercase and two segments, because D-15's id taxonomy is pinned as
- * `/^[a-z]+(?:\.[a-z]+)+$/` — a camelCased segment is not a spelling this catalogue admits. The
- * exported constant is what the dashboard composition hands its server as DATA;
- * `packages/dashboard-server` may not import this package, so the literal appears here once.
- */
 declare const RUNS_DETAIL_FUNCTION_ID = "runs.detail";
 
 declare const RUNS_EVIDENCE_FUNCTION_ID = "runs.evidence";
@@ -3024,112 +1350,36 @@ declare const RUNS_EVIDENCE_FUNCTION_ID = "runs.evidence";
  * package, so the literal appears here once.
  */
 declare const RUNS_ARTIFACT_FUNCTION_ID = "runs.artifact";
-/**
- * The run exists and holds no blob under that sha (D-15).
- *
- * A SEPARATE REFUSAL FROM `RunNotFoundError`, and separate because the two ask different things of
- * whoever reads them: an unknown run is a link that was never valid, while an absent blob is an
- * artifact that was collected, never written, or declared incomplete by its own ref. The dashboard
- * renders the second as a visible unavailable state (406 upgrades that rendering); rendering it as
- * "no such run" would tell an operator to go look for a run that is right there.
- *
- * Carries both coordinates so a surface can say WHICH artifact of which run is missing. The route
- * adapter does not echo them — a refusal body that quoted the request's own sha would be a
- * reflection this door has no reason to offer — but a CLI or chat caller holding the error can.
- */
 declare class EvidenceBlobAbsentError extends Error {
     readonly runId: string;
     readonly sha: string;
     constructor(runId: string, sha: string);
 }
 
-/**
- * Lowercase dot taxonomy (D-15): the locked `analysis` domain, one noun. The exported
- * constant is what plan 07's CLI and every later surface name; the literal appears here
- * once, and the parity-coverage suite picks the id up from the registry automatically.
- */
 declare const ANALYSIS_GET_FUNCTION_ID = "analysis.get";
 
-/**
- * Lowercase dot taxonomy (384 D-15): the `runs` domain, one noun.
- *
- * `runs.` rather than a new `digest.` domain, because what this returns is a fact ABOUT A RUN —
- * the same reason `runs.postprocessing` is not `postprocessing.get`. The exported constant is
- * what the CLI's `digest` verb, the tail's fetch pointer, 392's chat and M5 all name; the
- * literal appears here once, and the parity suite picks the id up from the registry.
- */
 declare const RUNS_DIGEST_FUNCTION_ID = "runs.digest";
 
-/**
- * Lowercase dot taxonomy (384 D-15): the `runs` domain, one noun.
- *
- * `runs.knowledge` and not `knowledge.run`, for the reason `runs.postprocessing` is not
- * `postprocessing.get` — what this returns is a fact ABOUT A RUN. The literal appears here once;
- * every surface names the exported constant and the parity suite picks the id up from the
- * registry.
- */
 declare const RUNS_KNOWLEDGE_FUNCTION_ID = "runs.knowledge";
 
 declare const RUNS_OVERVIEW_FUNCTION_ID = "runs.overview";
 
 declare const RUNS_LIST_FUNCTION_ID = "runs.list";
 
-/** The literal appears here once; every surface names the constant (384 D-15). */
+/** The literal appears here once; every surface names the constant. */
 declare const QUARANTINE_ADD_FUNCTION_ID = "quarantine.add";
 
-/**
- * Lowercase dot taxonomy (384 D-15): a new `quarantine` domain, one noun. Quarantine state is
- * neither a run, a memory nor an analysis — filing these verbs under an existing domain would
- * have made the taxonomy decorative, which is the same call 387 made for `entities`.
- *
- * The literal appears here once; the parity-coverage suite picks the id up off the registry.
- */
 declare const QUARANTINE_LIST_FUNCTION_ID = "quarantine.list";
 
-/** The literal appears here once; every surface names the constant (384 D-15). */
+/** The literal appears here once; every surface names the constant. */
 declare const QUARANTINE_RELEASE_FUNCTION_ID = "quarantine.release";
 
-/**
- * Lowercase dot taxonomy (384 D-15): the `agent.` domain's first verb.
- *
- * The literal appears exactly once, here. Every surface that names it — the `ask` command today,
- * the REPL and the MCP projection later — imports this constant, so the parity suite and the
- * catalogue read the same string as the dispatcher.
- */
 declare const AGENT_ASK_FUNCTION_ID = "agent.ask";
 
-/**
- * Lowercase dot taxonomy (384 D-15): the `agent` domain, already a pinned member of the conformance
- * suite's `domain-list.ts` because `agent.ask` lives there. No taxonomy widening — an explain is a
- * thing the AGENT does about itself, which is exactly what that domain's charter covers.
- *
- * The literal appears here once; the scenario rows, the composition and every later surface name
- * this constant.
- */
 declare const EXPLAIN_FUNCTION_ID = "agent.explain";
 
 declare const AUTHORING_DRAFT_VERIFY_FUNCTION_ID = "authoring.draft.verify";
 
-/**
- * What a refusal NAMES. Every field is evidence a reader can act on, not a summary of a verdict.
- *
- * `matchedRef` is the reference a caller hands to `entities.resolve`, spelled
- * `<filePath>::<testName>` — the same spelling `adds-value.ts`'s gate reason already prints, so
- * the two surfaces that name a suite test name it the same way.
- *
- * IT IS NOT A `TST-###` SHORT-ID, and that is measured rather than an omission. `ENTITY_KINDS`
- * reserves `TST`, but a short-ID exists only once something SIGHTS the entity, and sighting is
- * what mints the permanent address — `resolver/resolve.ts` states that no creation path anywhere
- * calls the ledger, so a refusal could not mint one without becoming a write on a read path.
- * Measured further: `composeLocalAgent()` wires exactly one sighting source, the memory one, so
- * NO suite test has a `TST-###` on any host in this build. Printing one would publish an address
- * that resolves to nothing, which is precisely ENTY-01's never-guess failure. The durable identity
- * is what this build can name truthfully, so it is what the refusal names; when a `TST` sighting
- * source lands, this field is the one place that has to change.
- *
- * `threshold` rides along because a refusal that reports 0.52 without reporting what it was
- * compared to tells an author nothing about whether their draft was borderline.
- */
 interface DedupEvidence {
     readonly score: number;
     readonly matched: SuiteTestIdentity;
@@ -3208,18 +1458,6 @@ interface RouterFailurePoint {
     /** Which path produced the verdict. Absent ⇒ the failure was not definitive. */
     readonly verdictSource?: VerdictSource;
 }
-/**
- * The application looks wrong, or the evidence does not say clearly enough to risk repairing — so
- * the loop STOPS here and reports what the run said.
- *
- * Carries `failurePoint` and `evidenceRefs`, neither of which exists on {@link RepairRoute}.
- * `failurePoint` is nullable because rule 4 admits a member that failed at the member level with
- * no step verdict to point at; `evidenceRefs` is not, because a stop a reader cannot trace is not
- * a report.
- *
- * 2026-09-02 (Phase 411): the proposal arm for a correctly-failing draft left with the Issue-slot
- * cleanup.
- */
 interface StopRoute {
     readonly kind: 'stop';
     readonly signalClass: RouterStopSignalClass;
@@ -3227,20 +1465,6 @@ interface StopRoute {
     readonly evidenceRefs: readonly RunEvidenceRef[];
 }
 
-/**
- * The probe showed a step that used to pass now failing. The dynamic half's refusal.
- *
- * Distinct from the static one by NAME rather than by a flag, because the two are evidence of
- * different things: a static violation says the model asked to touch a protected step, and this
- * says it broke one WITHOUT asking. The second is the more interesting signal and would be lost
- * inside a shared class.
- *
- * ITS FOUR FIELDS ARE ONE COORDINATE, AND THEY NAME THE PROBED MEMBER (CR-01). A run record is
- * addressed by (runId, filePath, testName, stepIndex), so the run id alone is half an address —
- * and the half a reader would otherwise supply from the PRE-repair draft names a file this probe
- * never opened, because every applied patch set re-stages the candidate under its new digest. All
- * four are minted by this package from the candidate it probed; none is model text.
- */
 declare class PassingPrefixRegressedError extends Error {
     readonly stepIndex: number;
     readonly runId: string;
@@ -3279,21 +1503,6 @@ type RepairAbandonment = {
  */
 declare const AUTHORING_LOOP_STAGES: readonly ["brief", "dedup", "compile", "verify", "route", "compound"];
 type AuthoringLoopStage = (typeof AUTHORING_LOOP_STAGES)[number];
-/**
- * How one loop invocation ended.
- *
- * Discriminated on the CLOSED schema vocabulary, and all four arms are declared here in the
- * tracer even though only `drafted` is reachable from it. See the vocabulary's own doc block: a
- * union that grew an arm per plan would make plans 04-06 changes to the shape every consumer
- * branches on rather than new cases behind a discriminant they already read.
- *
- * The `stopped` arm carries the ROUTE and the abandonment facts and writes nothing — the op
- * projects the result's `stop` payload from it (411 D-05).
- *
- * 2026-09-30, 432 D-06: the `drafted` and `repaired` arms carry the WRITTEN-TEST RECEIPT where they
- * used to carry a proposal for a person to accept. The final draft is written to its target unless
- * its final receipt is `rejected`, and the receipt says which file was written or why none was.
- */
 type AuthoringLoopOutcome = {
     readonly kind: 'drafted';
     readonly draftRef: DraftRef;
@@ -3316,15 +1525,6 @@ type AuthoringLoopOutcome = {
     readonly draftRef: DraftRef;
     readonly receipt: DraftReceipt;
     readonly route: StopRoute;
-    /**
-     * ITS KIND AND ITS SPEND ARE ONE PARAMETER, so `repairAbandonment` and `repairIterations`
-     * land on the op's payload together or not at all (394-21, WR-09). Present as one object or
-     * absent — never two independent optionals, which could disagree: a kind with no spend, or a
-     * spend on a stop repair never touched, which reads as "repair was tried and cost nothing".
-     *
-     * `iterations` is `RepairOutcome.iterations` INCLUDING iterations a fence refused, which
-     * started nothing — which is why it is not derivable from the run ids `fanOut` counts (D-08).
-     */
     readonly abandonment?: {
         readonly kind: RepairAbandonment['kind'];
         readonly iterations: number;
@@ -3335,93 +1535,24 @@ interface AuthoringLoopInput {
     readonly scope: ScopeKey;
     /** Handed straight through to stage 4. See the op's input contract for what it costs. */
     readonly draftMode?: true;
-    /**
-     * The invoking session, threaded to EVERY receipt this invocation mints (394-17, D-12).
-     *
-     * Both of them: stage 4's own evaluation and the final stability gate a repaired candidate goes
-     * through. A thread that stopped at the first would attribute first-try drafts and silently
-     * unattribute every draft that needed repairing — the population a keep rate most needs.
-     */
     readonly sessionRef?: string;
 }
-/**
- * The fan-out ONE invocation of this loop can cost, in child `agent-qa run` processes (D-03/D-10).
- *
- * THE SINGLE PLACE THE THREE TERMS ARE ASSEMBLED, and the only caller of `computeFanOutBound` in
- * this package. The dispatch confirm renders what this returns and the finished proposal reports
- * against it, so the number a person consents on and the number they are shown afterwards are the
- * same function of the same input rather than two agreeing arithmetics. A surface recomputing
- * `N + K + N` for itself would be free to drift the moment either constant moved — which is what
- * mutation I of the phase's mutation driver (since removed) demonstrated rather than asserted.
- *
- * DRAFT MODE IS THE CASE WHERE THE TWO N TERMS DIFFER. A draft-mode caller asks for ONE cheap gate
- * run (rule 1 of the disposition table), but the FINAL stability gate still runs the pinned N on
- * the repaired candidate — `repairDraft` deliberately drops the draft-mode marker for it. So the
- * bound is `1 + K + N`, not `2 * 1 + K`, and it is the configuration the schema cells use to prove
- * the two terms stay separate: with the shipped constants they are both 3, and a collapse would be
- * invisible under default values.
- */
 declare function authoringFanOutBound(input: {
     readonly draftMode?: true;
 }): FanOutBound;
 interface AuthoringLoopDeps {
     readonly read: AuthoringReadPortLike;
-    /**
-     * The compile half, plus stage 5's run reader (394-06).
-     *
-     * The run capability rides this bundle rather than arriving as a third dep: see the port's own
-     * `runs` doc. What it buys the loop is that "can this host author" stays ONE question with one
-     * answer, which is the property D-01's composition rests on.
-     */
     readonly shelf: DraftShelfPortLike;
 }
-/**
- * What one invocation produced, and the stages it actually entered.
- *
- * `stages` is DATA the loop answers with, not a test hook. Plan 04's refusal ends an invocation
- * at stage 2 and plan 05's repair re-enters stages 3-4, so "where did this stop" and "how many
- * times did it iterate" are questions about a real invocation that a caller — and the funnel's
- * side counters (D-15) — has to be able to ask. It is also what makes the ordering claim
- * checkable at all: the trace is pushed by each stage as it is entered, so a reordered loop
- * reports a reordered trace.
- */
 interface AuthoringLoopResult {
     readonly outcome: AuthoringLoopOutcome;
     readonly stages: readonly AuthoringLoopStage[];
     readonly dedup: DedupScreening;
     /** Which named side counters this invocation incremented. See the vocabulary's doc block. */
     readonly sideCounters: readonly AuthoringLoopSideCounter[];
-    /**
-     * What was previewed at dispatch, beside the runs this invocation actually spent (WTST-08).
-     *
-     * ON THE RESULT AND NOT ONLY ON THE PROPOSAL ARM, because a stage-2 refusal has no arm — D-04
-     * ends it with no draft, no receipt and no envelope — and "this invocation cost nothing" is a
-     * fact a caller is entitled to for every outcome, not only the ones that produced something.
-     */
     readonly fanOut: FanOutReport;
-    /**
-     * What stage 3's one refinement round did (D-18).
-     *
-     * ABSENT exactly when the round never ran — a stage-2 refusal, or a compile refusal for a lost
-     * stated value — and present on every other invocation, including the ones where the round
-     * changed nothing. The
-     * distinction the field exists to keep is between a round that found nothing (`no-op`) and one
-     * whose emission could not be used (`not-applied`): both leave the draft alone, and only one of
-     * them is the loop working as designed.
-     */
     readonly refinement?: RefinementOutcome;
 }
-/**
- * Facts about an invocation that are counted BESIDE the funnel, never as a stage of it (D-15).
- *
- * A dedup refusal is the first member, and the distinction is the whole reason the vocabulary
- * exists. Plan 07 projects the loop as a funnel — how many intents reached compile, verify, a
- * keep-eligible receipt — and a refusal that was folded into a funnel stage would read as an
- * invocation the pipeline FILTERED. It is not: it is an invocation the pipeline never entered,
- * refused for a working-as-intended reason before any cost was incurred. Counting it inside the
- * funnel would inflate the filter rate with successes and break comparison against the reference
- * distribution, which is exactly the number the funnel exists to be compared against.
- */
 declare const AUTHORING_LOOP_SIDE_COUNTERS: readonly ["dedup-refused"];
 type AuthoringLoopSideCounter = (typeof AUTHORING_LOOP_SIDE_COUNTERS)[number];
 declare function runAuthoringLoop(input: AuthoringLoopInput, deps: AuthoringLoopDeps): Promise<AuthoringLoopResult>;
@@ -3440,37 +1571,8 @@ declare const CONFIG_TARGET_CREATE_FUNCTION_ID = "config.target.create";
 
 declare const CONFIG_TARGET_EDIT_FUNCTION_ID = "config.target.edit";
 
-/**
- * Lowercase dot taxonomy (384 D-15), three segments: the shipped `authoring` domain, `funnel` as
- * the subject and `get` as the verb — the `authoring.draft.verify` / `authoring.draft.write`
- * precedent, which is itself the `knowledge.records.inspect` one.
- *
- * NO UNDERSCORE, and that is a constraint rather than a style: `parity-coverage.test.ts` requires
- * every id to match the dot taxonomy, and `chat/tool-names.ts` REFUSES an id already carrying `_`
- * because such a name has two pre-images under the `.` ↔ `_` inverse. Since 392 D-07 binds every
- * registry op into the planner's toolset, an underscore id would raise `ChatToolNameError` for
- * the whole projection rather than merely looking unconventional.
- *
- * `funnel` and not `drafts` because the subject is the MEASUREMENT, not the drafts: a second verb
- * about drafts would file under `authoring.draft.` beside its two siblings, and filing this one
- * there would have made "get the drafts" and "get the funnel over the drafts" indistinguishable at
- * exactly the point a reader is choosing between them.
- *
- * The literal appears here once; the parity-coverage suite picks the id up off the registry.
- */
 declare const AUTHORING_FUNNEL_GET_FUNCTION_ID = "authoring.funnel.get";
 
-/**
- * The session-scoped directives: canon that maps to NO registry op.
- *
- * Closed and spelled once. `/model` changes how THIS SESSION behaves (D-04's model override and its
- * `model_change` event); `/help` and `/quit` are REPL chrome. None of them is a capability, which is
- * why none of them has a function id — and they are in the table anyway, because the table is the
- * vocabulary a person types and the meta-test demands a scenario for every row of it.
- *
- * 432-13 (D-14): `/pin` is gone. It was a session deny overlay over the op gate, and there is no op
- * gate; a clause spelled `/pin …` is now an ordinary clause nothing in the table resolves.
- */
 declare const CHAT_DIRECTIVES: readonly ["model", "help", "quit"];
 type ChatDirectiveName = (typeof CHAT_DIRECTIVES)[number];
 /**
@@ -3518,77 +1620,16 @@ type ChatResolution = {
 } | {
     readonly kind: 'unresolved';
 };
-/**
- * THE CANON. Ordered, and the order is the first-match walk (see `resolveClause`).
- *
- * No two rules overlap today, so the order is documentation rather than semantics — and it is
- * written in D-06's own listing order so it stays readable as one.
- */
 declare const CHAT_RESOLVER_TABLE: ChatResolverTable;
-/**
- * Stage 1 for one clause: the FIRST rule that binds, or `unresolved`.
- *
- * First-match rather than unique-match, and the table is ordered rather than a map, because D-06's
- * canon has forms that could legitimately overlap as it grows, and "the earlier, more specific rule
- * wins" is a rule a reader of the table can see. Precision is 1.0 by construction — every rule is
- * an exact predicate over the clause, so a miss is a miss and never a guess (D-09).
- */
 declare function resolveClause(table: ChatResolverTable, clause: string): ChatResolution;
-/**
- * One line of `/help`, in a shape a census can read (Phase 398 plan 09).
- *
- * WHY THE ENTRIES ARE STRUCTURED AND THE STRING IS DERIVED. `CHAT_HELP_TEXT` used to be ten
- * hand-aligned sentences, and a sentence is not something a test can join to anything: the only
- * assertion available over it was a substring match somebody remembered to write. The fields below
- * are the join keys — `alias` names the row of `CHAT_RESOLVER_TABLE` the line documents, and
- * `syntax` is the FORM A PERSON TYPES, first token and all — so "the help text agrees with what
- * chat understands" became a set comparison and "this line claims an argument is optional" became a
- * probe of the shipped rule.
- *
- * THE CENSUS-TIE DECISION (398 plan 09, planned 2026-08-16, executed 2026-08-17 · D-01/SC-1).
- * The discretion call was whether help re-derives from the committed capability catalog or stays
- * here with a mechanical tie. It stays HERE. `packages/agent` is storage-neutral — it cannot read a
- * committed artifact off disk without acquiring a filesystem dependency the whole package is built
- * to not have — so re-deriving at runtime would move help out of the package that owns the
- * vocabulary and into the one that ships bytes. The tie gives the same guarantee without the move:
- * `packages/cli/src/__tests__/conformance/help-census.test.ts` set-equals these aliases against the
- * catalog's alias rows plus the shipped directives plus the passthrough, in BOTH directions, so a
- * help line with no capability behind it and a capability with no help line are each a named RED.
- * The header's one-list law is unchanged; what changed is that it is now enforced rather than
- * asked for.
- */
 interface ChatHelpEntry {
     /** The `CHAT_RESOLVER_TABLE` row this line documents. The census's join key. */
     readonly alias: string;
-    /**
-     * What a person types, verbatim, including the leading `/` where there is one.
-     *
-     * `<angle>` marks a REQUIRED argument and `[square]` an optional one, and the distinction is
-     * load-bearing rather than typographic: a conformance cell reads it and drives the shipped rule
-     * with the bare verb, so a line promising that a verb works alone when the rule refuses it — the
-     * exact drift this plan found on `digest` — is a failure rather than a reading.
-     */
     readonly syntax: string;
     /** What the line says the verb does. */
     readonly summary: string;
 }
-/**
- * What `/help` prints, one entry per row of the table above (Phase 392 plan 08, D-06).
- *
- * IT LIVES BESIDE THE TABLE, and that is the point rather than the filing: the canon a person can
- * type is `CHAT_RESOLVER_TABLE`, and help text kept anywhere else would be a second list of what
- * chat understands, free to drift from the one that actually routes. `/fn` is named explicitly
- * because it is the reach lever — every registry op is one deterministic branch away, which is why
- * the alias set stays thin (D-06).
- */
 declare const CHAT_HELP_ENTRIES: readonly ChatHelpEntry[];
-/**
- * What `/help` prints, RENDERED from the entries rather than spelled a second time.
- *
- * The string is still the export `composeLocalAgent`'s directive handler returns, because a person
- * types `/help` and reads sentences. What is gone is the possibility of the sentences and the join
- * keys disagreeing: there is one list, and this is a projection of it.
- */
 declare const CHAT_HELP_TEXT: string;
 
 /** One line off a session file, with the number an editor would show the person reading it. */
@@ -3623,7 +1664,7 @@ interface SessionRepair {
  * refuses a foreign header before this function is called, and it is pinned by a test anyway.
  */
 declare function repairSession(lines: readonly SessionLogLine[], options: RepairSessionOptions): SessionRepair;
-/** One line of rebuilt conversation. Refs and one-liners only — never a payload body (D-18). */
+/** One line of rebuilt conversation. Refs and one-liners only — never a payload body. */
 interface ChatReplayMessage {
     readonly role: 'user' | 'assistant';
     readonly text: string;
@@ -3634,19 +1675,6 @@ interface SessionReplay {
     /** Every turn the log records as interrupted, however it was interrupted. */
     readonly abortedTurnIds: readonly string[];
 }
-/**
- * Rebuild the live conversation a resumed session continues from, over REPAIRED events.
- *
- * IT RUNS AFTER REPAIR AND BEFORE ANY PRUNE, and the order is not decoration: replaying the raw
- * events of a crashed session yields a conversation in which the interrupted turn looks answered,
- * so a caller that pruned first would trim a conversation that never happened. CHAT-05 asks for
- * the repair on "the next turn, before pruning" for exactly this reason.
- *
- * AN ABORTED TURN IS EXCLUDED WHOLE, not merely truncated. Its user message is a question nobody
- * answered; carrying it forward would put an unanswered request in the model's context and invite
- * the next turn to act on it — which is the silent re-execution CHAT-05's repair exists to
- * prevent. The turn is not lost: it is on the log, with an `aborted` record naming it.
- */
 declare function replaySession(events: readonly ChatSessionEvent[]): SessionReplay;
 
 /** One piece of an utterance, as the splitter produced it. */
@@ -3661,24 +1689,7 @@ interface ResolvedClause {
     readonly functionId: string;
     readonly args: unknown;
 }
-/**
- * WHICH STAGE PROVED A BINDING (RESEARCH Pitfall 1 / 391 D-06).
- *
- * The same word names the caller mint and the action's provenance on purpose: the origin a clause
- * executes under is decided by which stage bound it, and giving the two ideas separate vocabularies
- * would let them drift into disagreeing about the same clause.
- */
 type ChatBindingStage = 'resolver' | 'planner';
-/**
- * One step of an execute verdict: a binding, and the stage that proved it.
- *
- * `source` is carried rather than re-derived, and that is a correctness decision rather than a
- * convenience. The engine has to mint a caller per action, and the only honest input to that choice
- * is which stage produced the binding — a fact reconciliation KNOWS and every later consumer would
- * have to guess at by matching the action back against the mapper set. A guess that matched on
- * `functionId` would mint `human` for a planner-planned call to an op the table also knows, which
- * is exactly the self-grant 391 D-06 withholds.
- */
 interface ClauseAction extends ResolvedClause {
     readonly source: ChatBindingStage;
 }
@@ -3695,159 +1706,43 @@ interface PlannerToolCall {
     readonly toolName: string;
     readonly input: unknown;
 }
-/**
- * A stage-2 failure the engine folds into a failed turn (CHAT-01).
- *
- * A transport error, an auth refusal or a provider outage is a fact about this turn, not a crash of
- * the session — so it is DATA rather than a thrown error, and the turn ends with a receipt instead
- * of a hang or a stack trace. The name is the provider's own refusal name where there is one, which
- * keeps it on the same footing as every other refusal a receipt carries.
- */
 interface PlannerStageFailure {
     readonly name: string;
     readonly message: string;
 }
-/**
- * What stage 2 produces: a PLAN, and never an effect.
- *
- * `toolCalls` carries EVERY call the model made, meta-tools included and in the order it proposed
- * them. Nothing is filtered out here, because stage 3 is the component that decides what a plan
- * means and a stage that pre-digested it would be making that decision one layer early, out of
- * sight of the reconciliation the whole design exists to route through.
- *
- * THERE IS NO `answer` FIELD, and its absence is load-bearing (392-14). This outcome used to carry
- * a convenience projection of the FIRST `answer_only` call's prose, which became a second prose
- * path the moment the tool contract moved to one call per answered clause: reconciliation counted
- * every claimed clause as answered and the person received the first answer only. The prose now
- * has exactly one carrier — the verdict's `answer`, built from the claims the merge actually
- * consumed — and a projection that could disagree with it no longer exists to be read.
- */
 interface PlannerStageOutcome {
     readonly toolCalls: readonly PlannerToolCall[];
     /** Present when the model could not be reached or refused; the turn fails, never hangs. */
     readonly failure?: PlannerStageFailure;
 }
-/**
- * Stage 2 — the tool-bound planner (CHAT-01).
- *
- * OPTIONAL AT THE COMPOSITION, and its absence is a real production posture rather than a stub:
- * a host with no model bound is HEADLESS, and the correct behaviour there is that any clause the
- * table cannot resolve fails the turn closed by name. A stubbed planner that answered "I could not
- * plan that" would say the same words about a completely different fact — that a model was asked
- * and declined — and the two need to stay distinguishable in the log.
- */
 interface PlannerStagePort {
     plan(request: PlannerStageRequest): Promise<PlannerStageOutcome>;
 }
-/**
- * What stage 2 is asked, INCLUDING WHOSE TURN IS ASKING (392 plan 13, CR-02).
- *
- * `sessionId` is not decoration on a prompt. The context a composition builds for this call — the
- * conversation replayed into the request, the model in force — are facts about ONE session, and a
- * composition serving two conversations at once has no other way to know which of them it is
- * assembling a request for. Without it the planner reads whichever conversation was published
- * most recently, which on an interleaved pair is the OTHER person's.
- */
 interface PlannerStageRequest {
     readonly utterance: string;
     readonly clauses: readonly ChatClause[];
     readonly sessionId: string;
 }
-/**
- * What stage 3 is given: what the table proved, and what the model proposed.
- *
- * `planned` is the model's RAW outcome rather than a set of resolved clauses, and the difference is
- * where the safety property lives. Aligning tool calls to clauses IS reconciliation — deciding
- * which proposal answers which part of the request, and whose binding wins where the table already
- * has one (D-12). A stage 2 that handed over pre-aligned clauses would have made that decision
- * already, in the one component whose input is untrusted model output.
- */
 interface ReconcileInput {
     readonly clauses: readonly ChatClause[];
     readonly mapped: readonly ResolvedClause[];
     readonly planned: PlannerStageOutcome;
 }
-/**
- * What stage 3 decides.
- *
- * `unhandled` and `execute` are mutually exclusive by contract rather than by shape, and the
- * asymmetry is D-10: reconciliation completes BEFORE the first side effect, so a verdict naming an
- * unhandled clause carries an empty execution plan and the turn ends with `executed == 0`.
- */
 type ReconcileVerdict = {
     readonly kind: 'execute';
     readonly plan: readonly ClauseAction[];
-    /**
-     * The prose a turn answers with when the model answered rather than acted (CHAT-01).
-     *
-     * It rides the EXECUTE verdict, with an empty plan in the pure case, because an answered turn
-     * completed — it did what was asked. Giving it a third verdict variant would have made
-     * "answered" a sibling of "refused", and every consumer would then have to remember that one
-     * of the two non-execute outcomes is a success.
-     */
     readonly answer?: string;
 } | {
     readonly kind: 'unhandled';
     readonly clause: ChatClause;
     readonly reason: string;
 };
-/**
- * Stage 3 — deterministic reconciliation (D-09 / D-12 / D-16).
- *
- * A pure function, supplied at engine CONSTRUCTION. The purity is what makes the mutation proof
- * possible at all: the differential composes the real host twice with two strategies and reads the
- * difference off a named scenario, without a single production code path knowing which it got.
- */
 type ReconcileStrategy = (input: ReconcileInput) => ReconcileVerdict;
-/**
- * The deterministic conjunction splitter (D-09).
- *
- * A seam rather than a hard-coded call because plan 02 replaces the tracer's whole-utterance
- * splitter with the quote-aware tokenizer, and the engine must not need editing for that.
- */
 type ClauseSplitter = (utterance: string) => readonly ChatClause[];
-/**
- * Per-stage caller minting (RESEARCH Pitfall 1 / 391 D-06).
- *
- * `FunctionCaller.origin` is a per-CALL fact, not a per-surface one: a person typing a canonical
- * alias IS a human acting, and a model planning a call is not, and both happen inside one turn, so a
- * receipt attributes each clause to the stage that bound it. 2026-10-02 (432-39, D-10/D-12): the
- * origin is attribution only; no op withholds anything by it.
- */
 interface CallerMint {
-    /**
-     * The caller for one binding stage.
-     *
-     * 2026-10-02 (432-39, D-02/D-12): no `sessionId` parameter. It only ever stamped the retired
-     * `FunctionCaller.sessionId` (392 plan 13), which nothing read after the session deny overlay left
-     * (432-13/432-19); the production mint ignored it, and the caller member is deleted.
-     */
     forStage(stage: ChatBindingStage): FunctionCaller;
 }
-/**
- * Stage-4's dispatch binding.
- *
- * A closure over `invokeFunction` supplied by the composition root, NOT a registry handle. Two
- * reasons and the second is the structural one: `agent`'s chat subtree would otherwise import the
- * registry it is registered inside, and — more importantly — a seam typed as "call this op for me"
- * cannot become a seam that runs a spec directly (384 FUNC-03).
- */
 type ChatInvokeBinding = (functionId: string, input: unknown, caller: FunctionCaller) => Promise<ChatInvokeAnswer>;
-/**
- * What an op answered, classified — the seam's return type since 399.1 (D-01/D-03/D-04/D-05).
- *
- * WHY THE VERDICT ARRIVES AS DATA RATHER THAN BEING COMPUTED HERE. The engine cannot classify a
- * result: the fold that knows which arm of an op's union is a refusal lives on that op's SPEC, and
- * this seam is deliberately not a registry handle (the paragraph above, 384 FUNC-03). The one place
- * in the system holding both the registry and this call is the composition root that mints the
- * binding, so that is where the fold runs and this is how its answer travels. The engine reads three
- * fields; it reaches for nothing.
- *
- * THIS TYPE IS WHY THE SEAM CHANGED AT ALL. `Promise<unknown>` was a seam that could carry the
- * RESULT and nothing about it, so the engine's only available derivation for a receipt status was
- * throw-versus-return — and every arm of a typed refusal returns. G-399-2 is that gap measured: a
- * credential-blocked config mutation reported `executed` in green.
- */
 interface ChatInvokeAnswer {
     /**
      * The op's own result, masked as the function layer returned it.
@@ -3856,112 +1751,29 @@ interface ChatInvokeAnswer {
      * every `agent.ask` client in this form; each surface's emit masks with the declared secrets.
      */
     readonly payload: unknown;
-    /**
-     * The classifier's answer, or the legacy verdict when the op declares no classifier.
-     *
-     * FAIL-CLOSED (D-03): a fold that throws, or answers something that is not a verdict, yields
-     * `failed` with a named outcome — never `executed`. An unreadable result might be a refusal, and
-     * success is the one claim a receipt must not default to.
-     */
     readonly verdict: ClauseVerdict;
     /** The op's declared render fold, or `[]`. ADDITIVE — these lines never replace the payload. */
     readonly foldLines: readonly string[];
 }
-/**
- * CHAT-04's degrade pass, as a seam the tracer leaves empty.
- *
- * Declared now for the reason every other seat here is: plan 06 fills it over the shipped
- * `TokenAccounting` substrate, and an engine that grew a compaction call later would grow it in the
- * middle of the turn contract this file pins.
- *
- * IT IS HANDED THE REPLAY, AND THAT IS WHAT MAKES CHAT-05'S ORDERING STRUCTURAL. The requirement is
- * that the replay-safety repair runs BEFORE pruning, and a hook that received nothing would have to
- * fetch its own messages — at which point nothing in the type stops it fetching them from an
- * unrepaired source. Receiving an already-repaired replay leaves the degrade pass no other input to
- * prune, so "repair first" is a fact about the argument rather than a rule someone has to remember.
- */
 type CompactionHook = (context: {
     readonly turnId: string;
-    /**
-     * The session this turn belongs to (392 plan 13, CR-02).
-     *
-     * Beside `append` for the same reason `append` is here: what a pass produces — the pruned
-     * conversation — belongs to ONE conversation, and the sink a host publishes it into is one
-     * container per session. A hook that knew the turn but not the session could write a pruned
-     * history into whichever conversation asked most recently.
-     */
     readonly sessionId: string;
     /** The conversation as of this turn's start: repaired, aborted turns already excluded. */
     readonly replay: SessionReplay;
-    /**
-     * Where this pass's one event goes: the SESSION HANDLE of the turn being compacted (392-12).
-     *
-     * The hook used to hold an `emit` bound at composition time, which — while the adapter owned a
-     * single mutable descriptor — meant "the session whose open ran most recently" rather than "the
-     * session this turn belongs to". Passing the append IN makes the destination a fact about the
-     * call, so a compaction event cannot land in another conversation however many turns are in
-     * flight. The hook still holds no log of its own; it holds one turn's writer for the length of
-     * one call.
-     */
     readonly append: (event: ChatCompactionEvent) => Promise<void>;
 }) => Promise<void> | void;
-/**
- * What a `/model` directive did (Phase 392 plan 08, D-04).
- *
- * The handler applies the override and REPORTS the two model names, rather than emitting anything.
- * The engine is what turns the pair into a `model_change` event, through the same `diffChatConfig`
- * the per-turn config re-read uses — so there is ONE construction site for that event and the
- * `source` field is what distinguishes a person typing from a file changing underneath them.
- */
 interface ChatModelDirectiveOutcome {
     readonly from: string;
     readonly to: string;
     /** The line the surface prints back. The handler renders it, because it knows what it resolved. */
     readonly line: string;
 }
-/**
- * The session directives, as handlers a composition binds (D-04).
- *
- * EVERY MEMBER IS OPTIONAL, and an absent one is not a gap: the engine's refusal arm names an
- * unbound directive by name, which is the honest answer for a build that recognises `/model` and
- * cannot carry it out. A host that binds none behaves exactly as every host did before this seam
- * existed.
- *
- * A HANDLER MAY THROW, AND THROWING IS AN ANSWER. That refusal travels the engine's ONE refusal
- * path, so it leaves the same `mark_unhandled` row every other refused clause does.
- *
- * 432-13 (D-14): `/pin` and its handler are gone with the op gate they tightened.
- */
 interface ChatDirectiveHandlers {
     readonly model?: (name: string) => ChatModelDirectiveOutcome | Promise<ChatModelDirectiveOutcome>;
     readonly help?: () => string;
     readonly quit?: () => string;
-    /**
-     * THE BATCH PRE-FLIGHT: state the refusal before ANY directive of this turn is applied (392-14).
-     *
-     * The engine runs this over EVERY collected directive and only then applies the first one, so a
-     * throw here refuses the whole turn with zero effects. That is D-10's own shape — reconciliation
-     * completes before the first side effect — applied to a directive BATCH.
-     *
-     * IT MUTATES NOTHING, and that is the member's whole contract. Asking whether a directive CAN be
-     * carried out is a different act from carrying it out, exactly as `directiveBindingRefusal` is.
-     * Resolving and caching a value the apply will reuse is permitted, because a cache is not a
-     * session's state.
-     *
-     * OPTIONAL, so a host that publishes none is exactly as safe as it was: `runDirective`'s catch
-     * remains the belt, and the only thing such a host loses is the batch guarantee.
-     */
     readonly validate?: (directive: ChatDirectiveName, argument?: string) => void | Promise<void>;
 }
-/**
- * Where the engine publishes the live turn state a surface renders from (RESEARCH Open Q2).
- *
- * A SINK rather than the container, so the engine can write the two facts only it holds — the
- * minted turn id and the turn's outcome — without acquiring the ability to read or reshape the
- * rest of a surface's state. The id is the load-bearing one: it is minted inside `runTurn`, and a
- * Ctrl+C handler that wants to write the explicit `aborted` event D-19 asks for has no other way
- * to name the turn it is interrupting.
- */
 interface ChatTurnStateSink {
     beginTurn(turnId: string): void;
     /**
@@ -3993,7 +1805,7 @@ interface ChatToolsetFingerprint {
     /** Present only when the caller genuinely observed the set — never reconstructed by guessing. */
     readonly ids?: readonly string[];
 }
-/** The configuration facts a chat session is sensitive to (D-04). */
+/** The configuration facts a chat session is sensitive to. */
 interface ChatConfigState {
     readonly model: string;
     readonly toolset: ChatToolsetFingerprint;
@@ -4006,80 +1818,12 @@ interface TurnEngineDeps {
     readonly sessionLog: SessionLogPort;
     readonly mint: CallerMint;
     readonly invoke: ChatInvokeBinding;
-    /** Absent ⇒ headless: an unresolved clause fails the turn closed BY NAME (D-08). */
     readonly planner?: PlannerStagePort;
     readonly compaction?: CompactionHook;
-    /**
-     * The configuration in force RIGHT NOW for THIS SESSION, re-read per turn (D-04, CR-02).
-     *
-     * A THUNK rather than a value, and that is the whole of "config changes are events": a value
-     * captured at construction would be the configuration the host started with, and the drift this
-     * seam exists to detect is precisely the case where the file changed underneath a running
-     * session. Absent ⇒ this host does not re-read, and nothing is claimed about drift — which is
-     * different from claiming there was none, and is why the seam is optional rather than defaulted.
-     *
-     * IT IS HANDED THE SESSION for the reason `state` below is: the answer includes the model in
-     * force, a `/model` override is session-scoped by D-04, and a composition-wide re-read would
-     * report one session's override as every session's drift.
-     */
     readonly config?: (sessionId: string) => ChatConfigState | Promise<ChatConfigState>;
-    /**
-     * The session directives, where a host binds any, RESOLVED PER SESSION (D-04 / CR-02).
-     *
-     * Absent, or absent for one directive, means the refusal arm below names it. That is not a
-     * degraded mode: a build that recognises `/model` and cannot carry it out should say so, and the
-     * `mark_unhandled` row it leaves is what makes the gap countable.
-     *
-     * A FACTORY, because a directive mutates a session: `/model` moves the model this conversation
-     * plans under, `/quit` asks THIS loop to end. Handlers bound once per composition would carry
-     * those effects to whoever asked next (W-03).
-     */
     readonly directives?: (sessionId: string) => ChatDirectiveHandlers;
-    /**
-     * Where the live turn state a surface renders from is published, PER SESSION (Open Q2, CR-02).
-     *
-     * The turn id goes out at the START of the turn rather than with the result, and that ordering is
-     * the whole reason the seam exists — an interrupted turn never produces a result, so a Ctrl+C
-     * handler that waited for one could never name the turn it was interrupting (D-19's graceful arm).
-     *
-     * A FACTORY OVER THE SESSION ID, resolved once per turn from the header `open()` returned. What
-     * this sink carries — the turn in flight, the conversation, the model — are facts about ONE
-     * conversation, and a sink held per composition made them facts about whichever turn wrote last.
-     * The engine cannot resolve it any earlier than the open, because a turn that names no session is
-     * given one BY the adapter and the id is the adapter's answer rather than the caller's input.
-     */
     readonly state?: (sessionId: string) => ChatTurnStateSink;
-    /**
-     * This project's configured target vocabulary, for the PRE-DISPATCH write_test route (395-08,
-     * D-14/D-15 · CFGM-05).
-     *
-     * A THUNK for `config`'s reason: a scaffold applied earlier in this very turn changes the answer,
-     * and a value captured at composition would send the authoring dispatch that follows it against
-     * the vocabulary as it stood before the scaffold wrote anything (2026-10-02, 432-40: re-spelled
-     * from "before the person approved anything" — the scaffold writes in the call, D-05/D-14).
-     *
-     * BOUND FROM THE SAME PORT THE AUTHORING LOOP READS (`AuthoringReadPortLike.configuredTargetNames`),
-     * so "which targets does this project declare" has one answer on both sides of the dispatch. Two
-     * readings of that question would let this seam route on a vocabulary the loop then disagrees with,
-     * which is the sibling-input failure this project keeps rediscovering.
-     *
-     * ABSENT ⇒ NO ROUTING. A host that cannot name its targets dispatches authoring exactly as it did
-     * before this seam existed, and the loop's own backstop is unchanged. That is deliberately the
-     * permissive direction: this seam adds a scaffold offer and a refusal, and a host that cannot
-     * answer the question has not lost a guard — the backstop it always had is still there.
-     */
     readonly configuredTargets?: () => Promise<readonly string[]>;
-    /**
-     * Where a mid-turn artifact a person should read is written (395-13 · CFGM-05).
-     *
-     * DISPLAY-ONLY. Nothing handed to this port enters a decision, and nothing waits on it.
-     *
-     * 2026-09-30, 432-11 D-05/D-14: the `write_test` scaffold route writes the configuration in the
-     * scaffold call itself, so what this port shows is a receipt of a change already on disk: the
-     * summary, the files written and the diff. It is no longer a precondition of an approval, because
-     * there is no approval. An absent port, or one that fails, does not stop the turn; the clause
-     * receipt still names the files the scaffold wrote.
-     */
     readonly present?: (text: string) => void | Promise<void>;
     readonly now: () => string;
     readonly mintTurnId: () => string;
@@ -4091,56 +1835,9 @@ interface TurnEngine {
 
 declare function createTurnEngine(deps: TurnEngineDeps): TurnEngine;
 
-/**
- * The refusal sentence a fail-closed turn carries.
- *
- * It NAMES the clause (D-08). A message that said only "I could not do that" would leave a person
- * unable to tell which half of a compound request was refused, and would make a silent drop and a
- * loud refusal read identically in the log.
- */
 declare function unhandledReason(clause: string): string;
-/**
- * The deterministic override: what the table proved beats what anything else proposed.
- *
- * The mapped set is indexed by CLAUSE INDEX rather than by matching text, and that is the D-12
- * mechanism in miniature: the clause's position is its identity, so a planner entry for a clause
- * the table already resolved cannot displace the mapper's binding no matter how the model spelled
- * it.
- *
- * THE COUNTS MUST AGREE BEFORE ANYTHING BINDS. Every clause gets exactly one disposition —
- * mapped, answered, or needing a proposal — and the number of action calls the model made is
- * compared against the number of clauses in that third group. That comparison is the ONE place a
- * count disagreement is decided, and it happens between the passes, before a single binding exists:
- * a disagreement refuses the turn BY NAME (D-08) rather than shifting the alignment by one, so the
- * materialize walk below has no refusal arm at all. The count and the set it is compared against
- * come from the same pass, because a second predicate computing "which clauses need a proposal"
- * would be free to drift from the one the binder walks.
- *
- * WHEN NO CLAUSE NEEDS A PROPOSAL nothing can be mis-bound — no call is popped by anybody — and
- * the calls are discarded whole. This is a CHOICE, not an absence of alternatives: through the
- * engine there is always a clause a refusal could name here, because stage 2 is skipped entirely
- * when every clause is mapped (`turn-engine.ts`), so a non-empty proposal list beside an empty
- * needy list means at least one clause was ANSWERED. Naming it is available and is not taken. The
- * asymmetry this file has always had is what decides it: the model may lose a proposal, and the
- * person may never lose a request. A clause that was answered did not lose its request — its prose
- * reaches the person — so the discarded call costs the model, not the person. Ratified 2026-08-10
- * against the alternative of refusing by name, which would move this case and cost every such turn
- * a refusal instead of an answer.
- */
 declare const deterministicOverrideStrategy: ReconcileStrategy;
 
-/**
- * The model's answer for a turn it answers in prose (CHAT-01).
- *
- * A first-class action rather than the absence of one: a turn where the person asked a question
- * executes zero ops and returns text, so `the model planned nothing` has to stay distinguishable
- * against `the model answered` — two facts a reader of the log must be able to tell apart.
- *
- * (The backticks are not stylistic. `packages/arch`'s dependency lint reads every source line
- * looking for a specifier, and its pattern is one particular English word ahead of a quoted
- * phrase — so ordinary prose in that shape is reported as an undeclared package import. Two
- * sibling plans have already reddened `validate:arch` this way.)
- */
 declare const ANSWER_ONLY_TOOL_NAME = "answer_only";
 /** The two orchestration tools, and no others. */
 declare const CHAT_META_TOOL_NAMES: readonly ["answer_only", "mark_unhandled"];
@@ -4161,19 +1858,6 @@ declare function isChatMetaToolName(name: string): name is ChatMetaToolName;
  */
 declare function fromToolName(toolName: string): string;
 
-/**
- * Split one utterance into the clauses stage 1 routes.
- *
- * Pure, total and host-free: no clock, no config, no I/O, and no input throws. An unterminated
- * quote is not an error a person should have to hear about — it protects to end-of-utterance,
- * which over-protects (one clause where two were meant) rather than under-protects (a phantom
- * clause and a spurious refusal). Pitfall 5 says which way to be wrong. An unterminated BRACKET
- * gets the identical answer for the identical reason (see {@link BRACKET_PAIRS}).
- *
- * Empty pieces are elided rather than preserved, so `status,,proposals` and `status, proposals`
- * are the same request. A clause whose text is empty could name nothing in a refusal, and D-08
- * requires that a fail-closed turn name what it could not do.
- */
 declare function splitClauses(utterance: string): readonly ChatClause[];
 
 /** What the last turn did, as a surface renders it. Absent before the first turn of a session. */
@@ -4185,22 +1869,7 @@ interface ChatLastTurn {
 }
 /** A frozen view of the session's live state. Handed out per read, never the live object. */
 interface ChatStateSnapshot {
-    /**
-     * The model in force RIGHT NOW, after any `/model` this session ran.
-     *
-     * This is the value the config re-read compares against, and that is why the override lives here
-     * rather than in a variable beside it: a thunk that kept answering the composed model would emit
-     * a `model_change` straight back on the next turn, undoing the verb it just recorded (392-07).
-     */
     readonly activeModel: string;
-    /**
-     * The turn currently in flight, or absent between turns.
-     *
-     * The ONLY thing that can name an interrupted turn. A SIGINT handler has no other way to write
-     * the explicit `aborted` event D-19's graceful arm asks for — the id is minted inside the engine
-     * and a surface never sees it until the turn result comes back, which for an interrupted turn is
-     * never.
-     */
     readonly activeTurnId?: string;
     /** The conversation as compaction left it, oldest first (see the module head for the direction). */
     readonly conversation: readonly ModelMessage[];
@@ -4208,13 +1877,6 @@ interface ChatStateSnapshot {
     /** `/quit` asked the loop to end. The REPL reads it; nothing in the engine acts on it. */
     readonly closing: boolean;
 }
-/**
- * The mutable container. The engine writes; the surface reads.
- *
- * Deliberately NOT an event emitter. A REPL renders after each turn returns, and a subscription
- * would be the seam through which a surface started reacting to a turn mid-flight — which is the
- * streaming design M5 owns, not a thing to half-build here.
- */
 interface ChatStateContainer {
     read(): ChatStateSnapshot;
     beginTurn(turnId: string): void;
@@ -4261,29 +1923,6 @@ declare function parseScenario(document: unknown, expected: {
     readonly id: string;
 }): ChatScenario;
 
-/**
- * The pinned ceiling: at most one refusal per five `should_execute` scenarios.
- *
- * A PINNED CONSTANT WITH A RETUNE COMMENT, NEVER CONFIG (386 D-15). A configurable ceiling is a
- * ceiling that gets raised the first time it is inconvenient, at which point it measures the
- * patience of whoever raised it.
- *
- * OWNER: the chat orchestration subsystem (Phase 392, CHAT-03).
- *
- * RETUNE WHEN, and only when:
- *   - the corpus GROWS through a deliberate `SCENARIO_CORPUS` bump, and the new members change what
- *     a representative request looks like. At the corpus size this pin ships against, 1/5 leaves no
- *     slack at all on the live lane — three `should_execute` live scenarios means the first refusal
- *     exceeds it. That is deliberate for a young corpus: with three cells, one miss IS a routing
- *     regression, and a tolerance that hid it would be a tolerance for nothing observable.
- *   - a MEASURED live rate sits consistently far from the pin in either direction across several
- *     gate runs. Consistently far below means the pin has stopped being a gate; consistently just
- *     above on requests that genuinely cannot be served means the corpus admitted cells the build
- *     was never going to route, and the fix is the corpus, not the number.
- *
- * A retune moves this constant AND `SCENARIO_CORPUS_VERSION`, so a rate recorded in any SUMMARY
- * stays attributable to the pair it was measured against.
- */
 declare const MARK_UNHANDLED_CEILING: {
     readonly num: 1;
     readonly den: 5;
@@ -4298,13 +1937,6 @@ interface MarkUnhandledCounts {
     readonly unhandledCount: number;
     readonly denominator: number;
 }
-/**
- * Count the refusals in a session-event stream against a caller-supplied denominator.
- *
- * The denominator is a PARAMETER rather than something this module derives, and that is the D-15
- * discipline expressed as a signature: a function that could count scenarios for itself would be
- * one refactor away from counting files on a disk.
- */
 declare function computeMarkUnhandledRate(events: readonly ChatSessionEvent[], denominator: number): MarkUnhandledCounts;
 /**
  * Has the corpus exceeded the pinned ceiling?
@@ -4320,118 +1952,6 @@ declare function computeMarkUnhandledRate(events: readonly ChatSessionEvent[], d
  */
 declare function ceilingExceeded(counts: MarkUnhandledCounts): boolean;
 
-/**
- * The corpus this build measures against.
- *
- * BUMPED WHENEVER THE CORPUS STOPS BEING THE SAME CORPUS — a member added or removed, an
- * expectation kind flipped, or an utterance re-authored. A recorded rate can then always be
- * attributed to a known set, and a rate quoted without one is a number whose meaning cannot be
- * reconstructed after the next scenario lands.
- *
- * v1 — 392 plan 02 seeded 13 deterministic + the canon compound pair; 392 plan 08 flipped the four
- *      directive scenarios to `should_execute` before this manifest existed.
- * v2 — 392 plan 09 admits the `planner/` seeds (the live lane's natural-language arm).
- * v3 — 392 plan 09, after the FIRST live execution: `run-42-and-digest`'s digest clause names its
- *      run (the original was unsatisfiable under D-10's pre-flight atomicity — see that file), and
- *      `list-recent-runs` is re-authored as a request to DO something rather than a question about
- *      the project.
- * v4 — 392 plan 11, the gap round for 392-VERIFICATION's CR-03 and CR-04: two `compound/` cells
- *      admitted, both `fail_closed`, so the ceiling's `should_execute` denominators are unmoved
- *      (11 hermetic, 3 live) and the two defects the corpus could not see now have permanent
- *      cells. `pin-and-write-test` is the corpus's first HERMETIC compound cell — both halves are
- *      deterministic, and its lane is named as an exception in `scenario-manifest.test.ts` rather
- *      than derived from its class. The verifier's third probe (two overlapping sessions on one
- *      composition, CR-01/CR-02) is deliberately NOT a cell here: the scenario runner is
- *      single-turn by design, so it lands as a composition-level concurrency test in plan 392-12.
- * v5 — 392 plan 14, the SECOND gap round for 392-VERIFICATION's round-2 gap: two more `compound/`
- *      cells, both `fail_closed` and both HERMETIC, so the denominators stay 11 hermetic / 3 live.
- *      `pin-and-pin-nonsense` is the multi-directive arm the runner's fail_closed side-effect
- *      assertion could not reach while `pin-and-write-test` was the only directive cell;
- *      `run-42-and-delete-root-empty-answer` is the hermetic sibling of the live CR-03 cell,
- *      carrying the empty-prose `answer_only` shape through a scripted planner so the class is
- *      proved per commit rather than only behind the announced-skipped live gate (W-08).
- * v6 — 392 plan 15, the THIRD gap round, for 392-VERIFICATION round 3's CR-01: one more `compound/`
- *      cell, `fail_closed` and HERMETIC, so the denominators stay 11 hermetic / 3 live.
- *      `run-42-and-summarise-extra-call` is the configuration the corpus had in NEITHER lane — a
- *      table-mapped clause beside a planner-bound one on a turn that completed — with a scripted
- *      planner emitting an extra action call about the MAPPED clause. Pre-fix that call shifted the
- *      binding of every later clause and executed with the model's own arguments; the cell is what
- *      makes the arity accounting's refusal observable per commit rather than only in a unit.
- * v7 — 394 plan 11, THE ARRIVAL FLIP, and the first version whose size does not move. 392 plan 08
- *      wrote D-08's flip law and committed three cells asserting that no capability could author a
- *      test; 394 registered the six-stage loop as `authoring.draft.write`, so two of those three
- *      change arm: `planner/write-test-for-checkout` and `compound/write-test-2fa-and-run`, both
- *      LIVE, taking the live denominator to 5. Both now pin planned == executed, because a cell
- *      that merely completed would be satisfied by a turn that planned the capability and never
- *      reached it — and reachability is the whole claim a flip makes.
- *
- *      TWO CELLS DELIBERATELY DO NOT FLIP, and each refusal is load-bearing for something 394
- *      does not ship. `deterministic/fn-unknown-op` addresses `write_test`, which was the SPEC's
- *      noun for the loop and is NOT a registered function id in this build (the id is
- *      `authoring.draft.write`); its `/fn` utterance therefore still reaches `invokeFunction` with
- *      an id nothing registers, which is the exact backstop that cell exists to prove, and flipping
- *      it would have made an unknown-op test pass for the wrong reason. So the HERMETIC denominator
- *      is unmoved at 11. `compound/pin-and-write-test` measures the CR-04 directive/pin probe — a
- *      refused turn that had already recorded a pin and an `approval_decision` row — and its
- *      write-test half is only the vehicle; flipping it would delete the corpus's one cell that
- *      names a directive on a turn that fails.
- *
- * v8 — 395 plan 09, THE CONFIG ARRIVAL, AND IT IS AN ADMISSION RATHER THAN A FLIP. 392 D-08 named
- *      the handoff as a flip — "the config `fail_closed` scenario moves to `should_execute`" — and
- *      395's research went looking for that cell across all 23 files and every line below. THERE IS
- *      NO CONFIG CELL IN v7. Nothing was ever admitted to flip, so executing the handoff faithfully
- *      means admitting one: `planner/config-edit-timeout`, LIVE and `should_execute`, taking the
- *      corpus to 24 and the live denominator to 6.
- *
- *      THE SIZE MOVING IS THE WHOLE DIFFERENCE, and it is why the size and the denominator are
- *      pinned side by side in `scenario-manifest.test.ts`. v7 was the first version whose size did
- *      not move: two cells changed arm and the live denominator rose by two, which is what a flip
- *      looks like from here. This version's size rises by one AND the denominator rises by one,
- *      which is what an admission looks like, and the pair is the only thing that tells them apart.
- *
- *      AN ADMISSION GROWS THE DENOMINATOR, WHICH IS THE MOVEMENT THE TREADMILL LAW EXISTS TO WATCH.
- *      Stated rather than slipped through: every gap-round cell since v4 was authored `fail_closed`
- *      precisely so the denominators did not move for work being done. This one is not a gap-round
- *      cell — it is a capability that did not exist in v7's build and does in this one, and the
- *      denominator it enters is the population the `mark_unhandled` ceiling is computed over. The
- *      rate reported after this commit is a rate about a DIFFERENT corpus, which is the sentence
- *      this version number exists to let a reader say.
- *
- * v9 — 398 plan 07, THE EXPLAIN ARRIVAL, and it is an ADMISSION on v8's shape rather than a flip.
- *      `agent.explain` did not exist in v8's build: "what can you do" had no reachable op, so the
- *      only honest outcomes were prose out of model memory or `mark_unhandled`, and no cell was
- *      ever admitted that could flip. Two `planner/` cells join — `what-can-you-do` and
- *      `how-do-i-explain` — taking the corpus to 26 and the live denominator to 8.
- *
- *      TWO CELLS AND NOT ONE, because XPLN-02 names two SHAPES of question rather than two
- *      wordings: an enumeration and a request for one capability's command. A planner that routed
- *      the first and answered the second from model memory is a real, reachable half-failure, and a
- *      corpus carrying only the enumeration form could not see it.
- *
- *      THE DENOMINATOR MOVES BY TWO, WHICH IS THE MOVEMENT THE TREADMILL LAW WATCHES. Stated rather
- *      than slipped through, on v8's own terms: these are not gap-round cells authored `fail_closed`
- *      to leave the ratio alone — they are a capability that did not exist in v8's build and does in
- *      this one. Every rate reported after this commit is a rate about a DIFFERENT corpus, which is
- *      the sentence this version number exists to let a reader say.
- *
- *      BOTH WERE UNRUN AT THE COMMIT THAT ADMITTED THEM. `AGENT_QA_LIVE_CHAT_CONFIG` was unset in
- *      that session, so the live gate announced its skip and neither utterance has met a model. The
- *      rows are corpus-pinned, not yet measured; the first live execution is the measurement, and
- *      if it routes to prose the UTTERANCE is what gets re-authored (392-09's precedent), never the
- *      assertion.
- *
- * v10 — 432 plan 13, TWO RETIREMENTS, and the size does not move. `/pin` and the bare `proposals`
- *      inbox alias left chat resolution with the op gate and the proposal inbox (D-05/D-14), so
- *      `deterministic/pin` and `deterministic/proposals` no longer name a table row. Each is KEPT and
- *      re-authored as a `fail_closed` absence cell ("re-spelled, never deleted"): the retired verb is
- *      an unroutable clause that refuses by name with zero executions. Both leave the hermetic
- *      `should_execute` denominator, taking it from 11 to 9; the live denominator is unmoved.
- *
- * DENOMINATORS AT THIS VERSION: 9 hermetic, 8 live. One canonical line, parsed by
- * `scenario-manifest.test.ts` and compared against the counts the list below actually has, so this
- * header cannot go on claiming numbers the corpus stopped having. Every other assertion in that
- * file reads the LIST, which is exactly why the header needed its own.
- */
 declare const SCENARIO_CORPUS_VERSION = 10;
 /**
  * One admitted scenario.
@@ -4446,48 +1966,9 @@ interface ScenarioCorpusEntry {
     readonly lane: ScenarioLane;
     readonly kind: ScenarioExpectationKind;
 }
-/**
- * The admitted set, in class order and then in the order each arrived.
- *
- * Deterministic scenarios run hermetic per commit; `planner` and `compound` run in the live-model
- * lane as a release gate (D-13). There is no third lane and no scenario outside this list.
- */
 declare const SCENARIO_CORPUS: readonly ScenarioCorpusEntry[];
 
-/**
- * The fraction of the context window at which chat asks for a degrade pass.
- *
- * PINNED, NOT CONFIG (386 D-15, 392 D-20). Spec §4.1 words this as a "configurable fraction,
- * per-model overridable"; that reading is deliberately narrowed here, and the narrowing is on the
- * record as a dated reconciliation note under CHAT-04 in `.planning/REQUIREMENTS.md` so an audit
- * does not score the spec-literal phrasing as a gap. Adding a knob later is additive; removing a
- * shipped knob is breaking, and a knob shipped before anybody knows what value to put in it is a
- * question asked of every user in place of an answer given by the tool.
- *
- * Owner: the chat orchestration surface (`packages/agent/src/chat`).
- * Retune trigger: a real session, on a named model, in which 0.5 is demonstrably wrong — a
- * conversation that overflows before this fires, or one degraded so early that answers lose
- * context nobody needed to lose. Per-model behaviour is derived from `getCeilings()` (which
- * composes `resolveCapabilities`) FIRST; a config field is the last resort, not the first.
- */
 declare const COMPACTION_RATIO = 0.5;
-/**
- * The smallest budget chat will ever ask a conversation to fit under, in tokens.
- *
- * PINNED, NOT CONFIG (386 D-15). This exists for the pathological ceiling, not the ordinary one:
- * on any real chat model half the window is far larger than this, so the floor never binds. It
- * binds when a capability lookup reports a tiny or bogus window, and what it does there is make
- * compaction GIVE UP rather than shred — a budget of a few hundred tokens would evict and truncate
- * a conversation down to a stub that answers nothing, which is a worse outcome than carrying the
- * tokens forward into the overflow handling the model layer already owns. A triggered pass under a
- * binding floor still runs the near-lossless hygiene stage and still reports honestly that it
- * freed little or nothing.
- *
- * Owner: the chat orchestration surface (`packages/agent/src/chat`).
- * Retune trigger: a real session on a small-window model where this floor is observably the reason
- * a conversation degraded badly — raise it if useful context is being cut, lower it only if a
- * genuinely small-window model is overflowing because the floor kept compaction from acting.
- */
 declare const CHAT_MINIMUM_CONTEXT = 8192;
 /**
  * The substrate's discriminated result, restated as the shape this module consumes.
@@ -4544,27 +2025,7 @@ interface CompactionPass {
     readonly messages: readonly ModelMessage[];
     readonly event?: ChatCompactionEvent;
 }
-/**
- * The whole of CHAT-04's trigger policy.
- *
- * Below the threshold nothing happens and nothing is logged, because nothing happened. At or above
- * it — the contract is `>=`, so the boundary triggers — the shipped degrade pass runs once under a
- * floored budget, and one event records what it cost whichever way it came out.
- *
- * A HISTORY OF FEWER THAN TWO MESSAGES IS A NO-OP (edge: CHAT-04/empty). Not a guard against a
- * crash — degrade handles both fine — but against a false record: degrade protects the final
- * message unconditionally, so on a one-message history there is nothing it may touch, and a pass
- * that ran would emit an event reporting a cost it did not pay.
- */
 declare function maybeCompact(input: CompactionPassInput): CompactionPass;
-/**
- * The repaired replay as messages the accounting substrate can measure.
- *
- * A straight carry-across: the replay is already refs and one-liners (D-18), and this is not the
- * place to decide what a conversation says. What it IS the place for is the ordering guarantee —
- * the replay handed to the hook has been repaired and has its aborted turns excluded, so the
- * conversation compaction prunes is the one CHAT-05 says it must be.
- */
 declare function replayToModelMessages(replay: SessionReplay): ModelMessage[];
 interface ChatCompactionHookDeps {
     readonly accounting: ChatTokenAccounting;
@@ -4589,20 +2050,6 @@ interface ChatCompactionHookDeps {
         readonly replay: SessionReplay;
     }) => readonly ModelMessage[];
 }
-/**
- * Bind the trigger policy as the engine's `CompactionHook`.
- *
- * ONE PASS PER TURN, AND NO LOOP AROUND IT. The engine calls this once, immediately after the
- * user message is logged and before stage 1 — so there is no arrangement in which a pass that
- * frees nothing is retried until it does. That is the structural half of "cannot wedge"; the other
- * half is that `maybeCompact` returns a conversation on every arm, which its suite pins as a
- * fixpoint over repeated application.
- *
- * THE EVENT GOES WHERE THE CALL SAYS, NOT WHERE THE CONSTRUCTION SAID (392-12, CR-01). The hook
- * carried an `emit` bound once per composition; with one adapter serving many sessions, "the log"
- * was not a fact a composition could know. `context.append` is the handle of the turn actually
- * being compacted, so this hook has no way to write into another conversation.
- */
 declare function createChatCompactionHook(deps: ChatCompactionHookDeps): CompactionHook;
 
 interface ChatPromptInput {
@@ -4612,17 +2059,8 @@ interface ChatPromptInput {
     readonly clauses: readonly ChatClause[];
     /** The model in force for this turn, as the session states it. */
     readonly activeModel: string;
-    /** Session facts as one-liners — refs and counts, never a serialized result (D-18). */
+    /** Session facts as one-liners — refs and counts, never a serialized result. */
     readonly facts?: readonly string[];
-    /**
-     * The conversation this turn continues, oldest first, already repaired and PRUNED.
-     *
-     * `ModelMessage`, and the direction is spelled once (392-06's flagged mismatch, resolved by plan
-     * 08's `chat-state.ts`). Log events become `ChatReplayMessage[]` through `replaySession`, that
-     * becomes `ModelMessage[]` through `replayToModelMessages`, compaction prunes in THAT form, and
-     * this block renders what compaction left. Taking the replay shape here would have needed an
-     * inverse projection that could only invent the turn ids pruning discarded.
-     */
     readonly conversation?: readonly ModelMessage[];
 }
 
@@ -4631,22 +2069,9 @@ type ChatLanguageModel = Exclude<LanguageModel, string>;
 /** What the prompt's context and volatile tiers state about the session, read per turn. */
 type ChatSessionPromptContext = Omit<ChatPromptInput, 'utterance' | 'clauses'>;
 interface PlannerStageDeps {
-    /** Built by the host through `createModel` and handed over — CHAT-06. */
     readonly model: ChatLanguageModel;
     /** The registry projection from `planner-tools.ts`. Execute-less, by that module's contract. */
     readonly tools: ToolSet;
-    /**
-     * Read once per REQUEST rather than captured at construction, because the model in force, the
-     * pending-count facts and the conversation all change WITHIN a session — a `/model` directive
-     * mid-session is the obvious case (D-04), and a stage holding a snapshot would prompt against a
-     * session that no longer exists.
-     *
-     * IT IS TOLD WHICH SESSION IS ASKING (392 plan 13, CR-02). A composition caches one stage per
-     * model NAME, so the same stage serves every session planning under that model; a thunk taking
-     * no argument therefore had exactly one conversation available to answer with, and on two
-     * interleaved turns that was whichever session published last. The request is the only thing
-     * here that knows whose turn this is.
-     */
     readonly context: (request: PlannerStageRequest) => ChatSessionPromptContext;
 }
 /**
@@ -4669,14 +2094,6 @@ declare function createPlannerStage(deps: PlannerStageDeps): PlannerStagePort;
 interface PlannerToolSource {
     list(caller: FunctionCaller): readonly FunctionDeclaration[];
 }
-/**
- * Build the model's entire action vocabulary from the capabilities this host declares.
- *
- * The caller is the PLANNER's caller, minted at the composition root with agent origin (Pitfall 1).
- * It matters here only through the registry's own safe-mode listing filter; the equivalence between
- * this set and the walk holds for whichever caller a host supplies, because both sides read the
- * same listing.
- */
 declare function projectPlannerTools(source: PlannerToolSource, caller: FunctionCaller): ToolSet;
 
 /**
@@ -4695,7 +2112,7 @@ interface AnalysisClusterMember {
     testIndex: number;
     testId: string;
 }
-/** Fingerprint value, count, member refs, representative ref — the whole DTO (D-16). */
+/** Fingerprint value, count, member refs, representative ref — the whole DTO. */
 interface AnalysisCluster {
     fingerprint: string;
     count: number;
@@ -4706,13 +2123,6 @@ interface AnalysisCluster {
         testIndex: number;
     };
 }
-/**
- * Group resolved verdicts by failure fingerprint (D-14) — a total, deterministic pure
- * function. Identical fingerprints merge; the same anchor under two classes stays two
- * clusters (the recipe's `::class` suffix). Output order: occurrence count descending,
- * then fingerprint lexicographic byte order; members by testIndex ascending. Empty input
- * answers an empty list, never a throw.
- */
 declare function clusterVerdicts(resolvedVerdicts: readonly Verdict[], handoff: CompletedRunHandoff): AnalysisCluster[];
 
 /**
@@ -4728,41 +2138,8 @@ interface StandInJobScript {
     readonly fail?: 'retryable' | 'permanent';
     readonly reason?: string;
 }
-/**
- * The host powers the two real post-run handlers need, injected by the composition (D-01).
- *
- * Both are things `agent` cannot do and must never learn to: reading a file is a host API in
- * a storageNeutral package, and the curation drain lives two packages away behind the writer
- * lease. Passing them as capabilities is what lets the handler bodies be real here while the
- * bindings stay where the ownership is — and it is also the seam a test uses to drive the
- * chain without a knowledge root.
- *
- * The whole interface is OPTIONAL at construction. A registry built without it keeps the
- * scripted stand-ins byte-identically, because several shipped suites — engine semantics,
- * kind registry, the kill matrix — drive the REAL kinds by scripting their payloads, and a
- * build where those kinds could only do real work would have no way to express "chain here,
- * fail permanently there" without a knowledge root and a run directory per case.
- */
 interface PostRunJobCapabilities {
-    /**
-     * The run's persisted handoff, addressed by `runId` alone.
-     *
-     * Hard-fails typed on a missing or malformed document rather than answering `undefined`:
-     * D-06 makes the PATH derived and the BYTES pinned, so "there is no handoff for this run"
-     * is a permanent condition of that run, never a transient one worth retrying.
-     */
     loadCompletedRunHandoff(runId: string): CompletedRunHandoff;
-    /**
-     * The per-run fold, and the fold's own report of whether it FINISHED (WR-03).
-     *
-     * `complete` is not a nicety on the side of the counts: the v51 fold answers `false` for
-     * candidate refusals, a cap exceeded, unresolved canaries, a failed outcome projection and
-     * requeues, and in every one of those cases it writes NO receipt so the run refolds later.
-     * Both production bindings used to return the counts alone, which is how a fold that refused
-     * became a stage the durable notification row called `done` — the one place in this phase
-     * where the record overstated what happened. It is part of the contract precisely so a
-     * binding cannot drop it silently: omit it and the binding stops typechecking.
-     */
     curateRun(input: {
         readonly runId: string;
         readonly executionContext: unknown;
@@ -4772,164 +2149,20 @@ interface PostRunJobCapabilities {
         readonly deprecated: number;
         readonly complete: boolean;
         readonly snapshot?: CurationSnapshot;
-        /**
-         * The candidates the fold's own receipt names, forwarded to the proposal stage (422 D-13).
-         *
-         * ADDITIVE-OPTIONAL rather than required, on this module's existing tolerance idiom, and the
-         * distinction is carried through rather than flattened: ABSENT means the binding reported no
-         * candidate ids at all, while `[]` means it reported that there were none. A required field
-         * would have forced every host and every harness that scripts a fold to invent a value for a
-         * question they are not the authority on — and the first thing a host invents here is `[]`,
-         * which is the one answer that is indistinguishable from a real empty fold.
-         */
-        readonly candidateIds?: readonly string[];
-        /** 2026-10-16 (442-10, D-17): why a fold that did not complete handed its run back. */
         readonly reason?: string;
     }>;
-    /**
-     * Put one run's analysis artifact durably on disk (389 D-09).
-     *
-     * Called INSIDE the author callback, before the verdicts-authored value is recorded — the
-     * authorship primitive records only after the callback returns, so by the time any chip can
-     * read `done` the sentence is already fetchable. Authored never overstates. The binding is
-     * the host's (`agent-local` derives the path from `runId` the same way it derives the
-     * handoff's — a job payload never carries a path); a synchronous throw here propagates out
-     * of the author, no checkpoint is recorded, and the declared bound adjudicates the retry.
-     */
     persistAnalysis(artifact: RunAnalysisArtifact): void;
-    /**
-     * One test's recorded outcome history, keyed the projection's way — `product` =
-     * `slugBranch(scope.key)` plus the stable test identity `filePath` + `testName`, NEVER
-     * `testId` (389 plan 02's key law). Feeds D-02's forced prior-build channel and the
-     * author's failure-history reasoning input. OPTIONAL: production hosts bind
-     * knowledge-local's `readTestOutcomeHistory` in plan 06; unbound, the author runs with a
-     * typed no-history diet — degraded, never a crash.
-     */
     readTestHistory?(query: {
         readonly product: string;
         readonly filePath: string;
         readonly testName: string;
     }): TestOutcomeHistoryLike | undefined;
-    /**
-     * D-01's TokenAccounting substrate entering as DATA — the estimator and input budget the
-     * author's compaction ladder walks against. OPTIONAL: plan 06 binds it from the same
-     * profile resolution as the job model; unbound, the packs travel whole (no ladder) and
-     * the model call carries whatever they weigh.
-     */
     analysisTokenBudget?: {
         readonly estimate: (text: string) => number;
         readonly inputBudget: number;
     };
-    /**
-     * D-02's capability-gated screenshot bytes: the CASS-02 evidence-blob store read,
-     * sha-addressed within one run's directory. OPTIONAL: plan 06 binds it at the production
-     * hosts; unbound — or with a model that does not advertise vision — the author's request
-     * is text-only, the L9 graceful degradation, never an error.
-     */
     readEvidenceBlob?(runId: string, sha: string): Uint8Array | undefined;
-    /**
-     * 2026-09-12, 422 D-19: which evaluation-root posture this run's circularity evidence was
-     * produced under.
-     *
-     * The rows themselves cannot answer it. An ABSENT root and a BROKEN one both publish the same
-     * empty ledger — that is precisely why 422-14 records the posture in its own durable file —
-     * and only the first earns `backing: 'declared-only'`. Reading that file is a host API, so the
-     * posture arrives here as a capability rather than as something this package learns to look up.
-     *
-     * OPTIONAL, and unbound is FAIL-CLOSED rather than permissive: a run whose posture nobody can
-     * state is treated as an ordinary `'eval-root'`, which is 422-11's own default and which makes
-     * an empty ledger an unresolved cross-check rather than a BYOM exemption. A throw is read the
-     * same way — a posture this process could not obtain is not a posture it may assume.
-     */
-    readMisdirectionRootPosture?(runId: string): MisdirectionRootPosture | undefined;
-    /**
-     * 2026-09-07, 417 D-18: typed now, bound nowhere in 417. Phase 422's
-     * propose-improvements binds this seam; the five-kind chain is untouched.
-     *
-     * 2026-09-11, 422 D-14: the proposal stage CALLS it. Its resolved receipt means the writer
-     * acknowledged persisting one (`ReplayGatePort`'s own contract) — anything else throws, and
-     * the handler reads the throw as a charged slot with an unknown outcome rather than as a
-     * screening result it may record.
-     */
-    runReplayGate?: ReplayGatePort['runReplayGate'];
-    /**
-     * Every committed bundle, as the reader entry's listing row (422 D-14).
-     *
-     * Structurally `KnowledgeReaderPort['listBundles']`, declared here rather than imported so this
-     * module keeps naming only schema DTOs. OPTIONAL: unbound, the Gate-1 leg is a typed no-op.
-     */
-    listBundles?(): Promise<readonly KnowledgeBundleSummary[]>;
-    /**
-     * One record's gate history, standing evidence and live verdict (422 D-14).
-     *
-     * The SELECTION reads this, not a store: a candidate is ungated when it carries no standing
-     * Gate-1 line under the current corpus digest, and that question is answerable from the
-     * committed receipts alone. OPTIONAL on the same terms as the listing.
-     */
-    gateReceiptsFor?(input: {
-        readonly candidateId: string;
-    }): Promise<KnowledgeGatesListResult>;
-    /**
-     * Which corpus this product's Gate-1 evidence is currently measured against (422 D-14).
-     *
-     * The digest is what makes a standing receipt a DECISION rather than a historical note: a
-     * receipt produced against a corpus that has since moved decided a different question. A
-     * posture that cannot resolve — a broken root, an unreadable floor — completes the stage
-     * `posture-unavailable` and spends nothing, which is a report rather than a retry loop.
-     */
-    readProposeCorpusPosture?(input: {
-        readonly product: string;
-    }): Promise<ProposeCorpusPosture>;
-    /**
-     * This job's durable Gate-1 charge, read back from the authoritative checkpoint (422 D-14).
-     *
-     * NARROW on purpose: one checkpoint, addressed by this job's own id, read-only. The handler is
-     * not handed a store, a checkpoint reader or a path — the composition that owns the store binds
-     * this one question, and `parseProposeGate1Allowance` below is the shape check it binds through.
-     */
-    readProposeGate1Allowance?(jobId: string): Promise<ProposeGate1AllowanceRead>;
-    /**
-     * The operator's `eval.gate1.maxPerJob` override, already resolved by the host (422 D-14).
-     *
-     * DATA rather than a reader, because the handler must not learn to read configuration. Absent
-     * means the recorded default, and the difference is disclosed on the charge as `cap.source` so
-     * a reader can tell a deliberate bound from an inherited one.
-     */
-    proposeGate1MaxPerJob?: number;
-    /**
-     * The third stage's work, as a NEUTRAL optional port (422 D-13).
-     *
-     * Optional on exactly the terms `readTestHistory` and `readEvidenceBlob` are: a host that does
-     * not bind it is not a broken host, it is a host that stages nothing. The stage still RUNS —
-     * it publishes its checkpoint, lands `done` and terminates the chain — and the record then
-     * reports a proposal stage that reached the port and proposed nothing, with no counts at all.
-     * That is a different sentence from `proposed: 0`, and the counts are omitted precisely so the
-     * two cannot be confused.
-     *
-     * Neutral in the same sense the two real handlers' other capabilities are: it names no store,
-     * no knowledge root and no model. The adversarial staging itself lives two packages away
-     * behind an operator admission seam this package may not reach, and binding it here would be
-     * the import edge the architecture refuses.
-     */
-    stageAdversarialProposal?(input: {
-        readonly runId: string;
-        readonly executionContext: ExecutionContext | undefined;
-        readonly candidateIds: readonly string[];
-        readonly upstream: ProposeImprovementsUpstream;
-    }): Promise<{
-        readonly proposed: number;
-        readonly skipped: number;
-    }>;
 }
-/**
- * The minimal structural mirror of knowledge-local's `TestOutcomeHistory` row (389 plan 02).
- *
- * Declared HERE rather than imported because the dependency points the other way — this
- * package never names knowledge-local — and structural typing makes the real
- * `readTestOutcomeHistory` record assignable unchanged at the plan 06 binding. It also
- * matches `evidence-diet.ts`'s `EvidenceTestHistory` member-for-member, so one capability
- * answer feeds both the diet's prior-build channel and the author's reasoning input.
- */
 interface TestOutcomeHistoryLike {
     readonly passes: number;
     readonly failures: number;
@@ -4941,172 +2174,9 @@ interface TestOutcomeHistoryLike {
     }[];
     readonly lastBuildOrdinal: number | undefined;
 }
-/**
- * What the two earlier stages already did, carried forward to the third (422 D-13).
- *
- * Every member is OPTIONAL and every absence is a real, different situation rather than a
- * default: no `analysisStatus` means this payload does not say what became of the analysis, and
- * no `curation` means it does not say what the fold committed. The terminal builder reads the
- * absences as absences — it never fills them with zeros — because this block exists precisely so
- * the record can report stages the finishing job did not run, and a block that guessed would be
- * a more confident lie than saying nothing.
- */
-interface ProposeImprovementsUpstream {
-    readonly verdictSummary?: RunNotificationVerdictSummary;
-    readonly analysisStatus?: 'done' | 'failed';
-    readonly curation?: {
-        readonly curated?: number;
-        readonly deprecated?: number;
-        readonly complete?: true;
-        readonly curationSnapshot?: CurationSnapshot;
-    };
-}
-/** The checkpoint the durable per-job Gate-1 charge is published on, before any invocation. */
-declare const PROPOSE_GATE1_ALLOWANCE_CHECKPOINT = "gate1-allowance-reserved";
-/**
- * How many Gate-1 calls ONE proposal job may spend (422 D-14).
- *
- * Four, beside the phase's other two Gate-1-adjacent recorded defaults, and the unit is the one
- * this layer always knows exactly: a CALL. A per-job bound rather than a per-run one because
- * the job is what carries a durable charge; and a bound at all because a fold that committed
- * forty candidates would otherwise hand the pump forty replays before the next run's tail could
- * get a lease. The number is a STATED budget with a stated rationale — bounded per-job replay
- * work — and not a measured one; nothing in this repo yet measures what a proposal stage should
- * be allowed to spend.
- */
-declare const PROPOSE_DEFAULT_MAX_GATE1_PER_JOB = 4;
-/** Where the bound came from, disclosed beside it so an operator can tell a default from a choice. */
-interface ProposeGate1Cap {
-    readonly value: number;
-    readonly source: 'config' | 'default';
-}
-/**
- * The durable charge, published before the first Gate-1 invocation (422 D-14).
- *
- * Every member is part of the IDENTITY of the charge rather than decoration. `jobId` and `runId`
- * are what let a resumed attempt refuse a reservation that belongs to somebody else instead of
- * silently adopting it. `product` and `corpusDigest` freeze what the selection was made against,
- * so a corpus that moved between the attempts cannot re-open a slot. `cap` travels with it
- * because a config change during a retry must not enlarge a charge already made. And
- * `selectedCandidateIds` is the charge itself: those slots are spent, whatever became of them.
- */
-interface ProposeGate1Allowance {
-    readonly jobId: string;
-    readonly runId: string;
-    readonly product: string;
-    readonly corpusDigest: string;
-    readonly cap: ProposeGate1Cap;
-    readonly selectedCandidateIds: readonly string[];
-}
-/**
- * What reading the persisted charge found.
- *
- * Three arms, and `unreadable` is NOT folded into `absent` — that is the whole safety property.
- * An absent charge permits a first selection; a charge this build cannot read means a previous
- * attempt may have spent slots this one cannot account for, and the only honest response is to
- * spend nothing.
- */
-type ProposeGate1AllowanceRead = {
-    readonly kind: 'absent';
-} | {
-    readonly kind: 'claimed';
-    readonly allowance: ProposeGate1Allowance;
-} | {
-    readonly kind: 'unreadable';
-    readonly reason: string;
-};
-/** What corpus the selection is made against, and whether it can be known at all. */
-type ProposeCorpusPosture = {
-    readonly kind: 'resolved';
-    readonly corpusDigest: string;
-} | {
-    readonly kind: 'unavailable';
-    readonly reason: string;
-} | {
-    readonly kind: 'no-root';
-};
-/** One candidate whose Gate-1 receipt exists and is readable, with the verdict it carries. */
-interface ProposeGate1Screened {
-    readonly candidateId: string;
-    readonly verdict: GateVerdict;
-}
-/**
- * What the proposal stage's Gate-1 leg did, as the durable record reports it (422 D-14).
- *
- * The four candidate-state members are deliberately NOT summable into one count:
- *
- *   `screenedGate1`          this attempt called the port and the writer acknowledged a receipt
- *   `recoveredGate1Receipts` a valid receipt was already on disk under the saved identity —
- *                            found, never generated here, and never claimed as this attempt's work
- *   `interruptedGate1`       a charged slot with no acknowledged and no recovered receipt. UNKNOWN,
- *                            which is its own outcome and not a quiet zero
- *   `ungatedRemaining`       eligible work the cap did not admit; it waits for a later run's
- *                            distinct job or the operator's replay-gate verb, and is never a refund
- */
-interface ProposeGate1Report {
-    readonly disposition: 'unbound' | 'no-candidates' | 'posture-unavailable' | 'allowance-unavailable' | 'claimed' | 'resumed';
-    readonly reason?: string;
-    readonly cap?: ProposeGate1Cap;
-    readonly reservedGate1: readonly string[];
-    readonly screenedGate1: readonly ProposeGate1Screened[];
-    readonly recoveredGate1Receipts: readonly ProposeGate1Screened[];
-    readonly interruptedGate1: readonly string[];
-    readonly ungatedRemaining: readonly string[];
-    readonly kindExcluded: readonly string[];
-    readonly stale: readonly string[];
-}
-/** What `proposals-authored` carries. `gate1` is ABSENT when no gate capability was bound. */
-interface ProposeImprovementsCheckpoint {
-    readonly runId: string;
-    readonly candidateIds: readonly string[];
-    readonly proposed?: number;
-    readonly skipped?: number;
-    readonly gate1?: ProposeGate1Report;
-}
-/**
- * Read the durable charge back out of a checkpoint read (422 D-14).
- *
- * STRICT, unlike this module's two payload readers, and the asymmetry is the point. Those read
- * bytes off a durable queue that an older build may have written, where refusing would strand
- * real work. This reads THIS job's own charge ledger, written by this build moments ago — so a
- * shape this build cannot read is not a generation gap, it is a ledger that cannot be trusted to
- * say what was already spent. Degrading it to `absent` would license a second selection against
- * a charge that already exists, which is exactly the over-spend the ledger exists to prevent.
- *
- * Exported so the composition that owns the store can bind a one-line reader: the envelope peel
- * and the shape check live HERE, where the shape is declared, rather than in each host.
- */
-declare function parseProposeGate1Allowance(outcome: JobCheckpointReadOutcome): ProposeGate1AllowanceRead;
-/**
- * The five declarations as a list, in the order the kind vocabulary declares them.
- *
- * The NO-CAPABILITY set: analyze-run and curate-memory carry their scripted stand-ins here,
- * byte-identically to what 385 shipped. Everything registry-driven that does not compose a
- * host — the conformance suite, the crash matrix, the kill matrix's adversarial legs — reads
- * this list, and every one of them scripts those two kinds by payload.
- */
 declare const REAL_JOB_KIND_DECLARATIONS: readonly JobKindDeclaration[];
-/**
- * A registry over exactly the five real kinds.
- *
- * A fresh registry per call rather than a module-level singleton: a registry is a small,
- * cheap value, and one shared instance is how a test that registers something extra ends up
- * changing what every other test in the process sees.
- *
- * With `capabilities`, analyze-run and curate-memory dispatch their REAL bodies (388 D-01 /
- * D-02); without, they keep the scripted stand-ins. The stand-ins are the HARNESS affordance,
- * not a shipped posture: both production compositions bind capabilities — `composeLocalAgent`
- * when the run tail supplies its curation drain (plan 02), and the daemon's own composition
- * through the same input. A caller that gets a stand-in is a caller that asked for one.
- *
- * The DECLARATIONS are identical in both cases. Only the two handler slots move, so a matrix
- * that derives its crash points from the declared schedule covers the real bodies with no
- * harness change at all — which is the design intent 385 D-09 stated and this is the phase
- * that spends it.
- */
 declare function createRealJobKindRegistry(capabilities?: PostRunJobCapabilities): JobKindRegistry;
 
-/** The frozen contract shape plan 01's `corpus-static-gates.test.ts` pinned (D-08). */
 interface AssertionStrengthStep {
     readonly text: string;
     readonly kind: 'assertion' | 'action';
@@ -5118,17 +2188,6 @@ interface AssertionStrengthResult {
     readonly falsifiable: boolean;
     readonly steps: AssertionStrengthStep[];
 }
-/**
- * The frozen proving suite's contract (D-08) — a projection, never a second judgment.
- *
- * `corpus-static-gates.test.ts` was committed RED against this exact signature before any of
- * this module existed, and it names its fields `text`/`kind` where the receipt schema names
- * them `stepText`/`role`. Renaming either side to agree with the other would have meant the
- * implementation editing the artifact that exists to constrain it, so the two spellings both
- * stand and this function carries the mapping. `vacuityHit` and `tautologyHit` are absent from
- * the projection because the frozen shape has no field for them — they survive on the receipt
- * rows, which is where D-11 says the author reads them.
- */
 declare function evaluateAssertionStrength(steps: readonly string[]): AssertionStrengthResult;
 
-export { AGENT_ASK_FUNCTION_ID, ANALYSIS_GET_FUNCTION_ID, ANSWER_ONLY_TOOL_NAME, AUTHORING_DRAFT_EDIT_FUNCTION_ID, AUTHORING_DRAFT_VERIFY_FUNCTION_ID, AUTHORING_DRAFT_WRITE_FUNCTION_ID, AUTHORING_FUNNEL_GET_FUNCTION_ID, AUTHORING_LOOP_STAGES, type AgentJobQueue, AmbiguousStepAddressError, type AnalysisArtifactReaderPort, type AnalysisCluster, type AnalysisClusterMember, type AuthoringFunnelPortLike, type AuthoringLoopDeps, type AuthoringLoopInput, type AuthoringLoopOutcome, type AuthoringLoopResult, type AuthoringLoopStage, type AuthoringReadPort, type AuthoringReadPortLike, type BoundRecordLlmAuthorship, CHAT_DIRECTIVES, CHAT_HELP_ENTRIES, CHAT_HELP_TEXT, CHAT_MINIMUM_CONTEXT, CHAT_RESOLVER_TABLE, COMPACTION_RATIO, CONFIG_AUTH_SET_FUNCTION_ID, CONFIG_FIELD_SET_FUNCTION_ID, CONFIG_HOOK_ADD_FUNCTION_ID, CONFIG_TARGET_CREATE_FUNCTION_ID, CONFIG_TARGET_EDIT_FUNCTION_ID, type CallerMint, type CancelJobInput, type CapabilityCatalogPort, type ChainJobIds, type ChainTerminalRecord, type ChatBindingStage, type ChatClause, type ChatCompactionHookDeps, type ChatConfigState, type ChatDegradeOptions, type ChatDegradeOutcome, type ChatDirectiveHandlers, type ChatDirectiveName, type ChatHelpEntry, type ChatInvokeAnswer, type ChatInvokeBinding, type ChatLanguageModel, type ChatLastTurn, type ChatModelDirectiveOutcome, type ChatReplayMessage, type ChatResolution, type ChatResolverEntry, type ChatResolverRule, type ChatResolverTable, type ChatStateContainer, type ChatStateSnapshot, type ChatTokenAccounting, type ChatToolsetFingerprint, type ChatTurnPort, type ChatTurnStateSink, type ClaimNextOptions, type ClauseAction, type ClauseSplitter, type ClauseVerdict, type ClockPort, type CompactionHook, type CompactionPass, type CompactionPassInput, type ConfigFieldSetResult, type ConfigFieldValue, type ConfigFileBytes, type ConfigFileSet, type ConfigFilesPortLike, type ConfigPathFacts, type ConfigReaderPort, type ConfigScaffoldContentPortLike, type ConfigStructuredValue, type ConfigValidatePortLike, type ConfigValidation, type ConfigValidationIssue, type CreateAgentJobQueueOptions, type CreateChatStateInput, type CreateFunctionRegistryOptions, type DraftReceiptsReadPortLike, type DraftShelfPortLike, type DraftStageOutcome, DuplicateFunctionIdError, DuplicateJobKindError, EDITOR_LIVE_URL_FUNCTION_ID, EXPLAIN_FUNCTION_ID, type EntityDirectoryPort, EntityNotFoundError, EvidenceBlobAbsentError, type EvidenceBlobReaderPort, type ExplainAbstentionRecord, type FallbackContinuationInput, type FallbackContinuationProducer, type FunctionBindingStatus, type FunctionDeclaration, type FunctionDeps, FunctionInputError, FunctionNotBoundError, type FunctionRegistry, type FunctionResultFold, type FunctionResultKind, type FunctionStream, Gate1ReceiptNotPersistedError, IncompleteJobKindDeclarationError, InconsistentJobKindDeclarationError, type JobAuthorCallback, type JobBackoffPolicy, type JobCancelOutcome, JobCancellationNotRequestedError, JobCancelledError, type JobCheckpointContext, type JobCheckpointReadOutcome, type JobCheckpointRecord, type JobClaimOutcome, type JobCompleteOutcome, type JobEnqueueOutcome, type JobFailureDisposition, type JobHandler, type JobHandlerContext, type JobIdSource, type JobInsert, type JobKindDeclaration, type JobKindRegistry, type JobModelCapability, type JobModelOutput, type JobModelRequest, type JobPermanentFailureDisposition, type JobRecordedValueOutcome, type JobRequeueOutcome, type JobStoreDump, type JobStoreDumpRow, type JobStoreFence, type JobStorePort, KNOWLEDGE_GATES_LIST_FUNCTION_ID, KnowledgeGatesUnboundError, type KnowledgePort, type KnowledgeReaderPort, type KnowledgeReviewPort, LIVE_EMBED_PATH_PREFIX, LIVE_URL_TOKEN_VERSION, LIVE_URL_TTL_MS, type LiveViewPort, LiveViewUnavailableError, MARK_UNHANDLED_CEILING, type MarkUnhandledCounts, MissingIdempotencyKeyError, OPTIONAL_FUNCTION_DEP_KEYS, type OptionalFunctionDepKey, PROPOSE_DEFAULT_MAX_GATE1_PER_JOB, PROPOSE_GATE1_ALLOWANCE_CHECKPOINT, type PersistencePort, type PlannerStageFailure, type PlannerStageOutcome, type PlannerStagePort, type PlannerToolCall, type PostProcessingChainState, type PostProcessingJobRow, type PostProcessingReaderPort, type PostRunJobCapabilities, type ProposeCorpusPosture, type ProposeGate1Allowance, type ProposeGate1AllowanceRead, type ProposeGate1Cap, type ProposeGate1Report, type ProposeGate1Screened, type ProposeImprovementsCheckpoint, QUARANTINE_ADD_FUNCTION_ID, QUARANTINE_LIST_FUNCTION_ID, QUARANTINE_RELEASE_FUNCTION_ID, QuarantinedJobRequeueError, REAL_JOB_KIND_DECLARATIONS, RUNS_ARTIFACT_FUNCTION_ID, RUNS_DETAIL_FUNCTION_ID, RUNS_DIGEST_FUNCTION_ID, RUNS_EVENTS_FUNCTION_ID, RUNS_EVIDENCE_FUNCTION_ID, RUNS_KNOWLEDGE_FUNCTION_ID, RUNS_LIST_FUNCTION_ID, RUNS_LIVE_URL_FUNCTION_ID, RUNS_MARKS_HISTORY_FUNCTION_ID, RUNS_MARK_FUNCTION_ID, RUNS_MARK_PREVIEW_FUNCTION_ID, RUNS_OVERVIEW_FUNCTION_ID, RUNS_POST_PROCESSING_FUNCTION_ID, RUNS_START_FUNCTION_ID, type RanJobOutcomeBase, type ReconcileInput, type ReconcileStrategy, type ReconcileVerdict, type RecoverAbandonedClaimsInput, type RecoverAbandonedClaimsOutcome, type RecurrenceAnswer, type RecurrenceLadder, type RecurrenceProvider, type RecurrenceQuery, type RepairSessionOptions, type ReplayGatePort, type ReplayedRunEvent, type ResolvedClause, type RunDetailReaderPort, RunEndedWithoutVerdictError, type RunInvocationPort, type RunNextJobInput, type RunNextJobOutcome, RunNotFinishedError, RunNotFoundError, RunNotRecordedError, type RunsReaderPort, SCENARIO_CORPUS, SCENARIO_CORPUS_VERSION, type ScenarioCorpusEntry, type SessionLogLine, type SessionRepair, type SessionReplay, StaleJobStoreEpochError, type StandInJobScript, type StartedRun, type StepEvidenceAddress, type StepEvidenceLookup, StreamReplayFloorError, type SuiteOutcomeHistoryPortLike, type ToolsPort, type TurnEngine, type TurnEngineDeps, UndeclaredJobCheckpointError, UndeclaredJobSuccessorError, UnknownFunctionError, UnknownJobKindError, UnknownLiveEditorSessionError, UnknownRunError, authoringFanOutBound, ceilingExceeded, chainJobIdsForRun, clusterVerdicts, composeBanner, computeMarkUnhandledRate, createAgentJobQueue, createChatCompactionHook, createChatState, createFunctionRegistry, createJobKindRegistry, createPlannerStage, createRealJobKindRegistry, createTurnEngine, decodeBase64Url, deterministicOverrideStrategy, encodeBase64Url, evaluateAssertionStrength, foldFunctionResult, fromToolName, gatherSuiteStability, invokeFunction, isChatMetaToolName, liveUrlOf, maybeCompact, mintLiveUrlToken, parseProposeGate1Allowance, parseScenario, projectAuthoringFunnel, projectPlannerTools, recordLlmAuthorship, renderAnalysisClusterBlock, renderVerdictSentence, repairSession, replaySession, replayToModelMessages, resolveClause, runAuthoringLoop, scenarioRelativePath, scopeReceiptsToWindow, splitClauses, unhandledReason, validateLiveUrlToken };
+export { AGENT_ASK_FUNCTION_ID, ANALYSIS_GET_FUNCTION_ID, ANSWER_ONLY_TOOL_NAME, AUTHORING_DRAFT_EDIT_FUNCTION_ID, AUTHORING_DRAFT_VERIFY_FUNCTION_ID, AUTHORING_DRAFT_WRITE_FUNCTION_ID, AUTHORING_FUNNEL_GET_FUNCTION_ID, AUTHORING_LOOP_STAGES, type AgentJobQueue, AmbiguousStepAddressError, type AnalysisArtifactReaderPort, type AnalysisCluster, type AnalysisClusterMember, type AuthoringFunnelPortLike, type AuthoringLoopDeps, type AuthoringLoopInput, type AuthoringLoopOutcome, type AuthoringLoopResult, type AuthoringLoopStage, type AuthoringReadPort, type AuthoringReadPortLike, type BoundRecordLlmAuthorship, CHAT_DIRECTIVES, CHAT_HELP_ENTRIES, CHAT_HELP_TEXT, CHAT_MINIMUM_CONTEXT, CHAT_RESOLVER_TABLE, COMPACTION_RATIO, CONFIG_AUTH_SET_FUNCTION_ID, CONFIG_FIELD_SET_FUNCTION_ID, CONFIG_HOOK_ADD_FUNCTION_ID, CONFIG_TARGET_CREATE_FUNCTION_ID, CONFIG_TARGET_EDIT_FUNCTION_ID, type CallerMint, type CancelJobInput, type CapabilityCatalogPort, type ChainJobIds, type ChainTerminalRecord, type ChatBindingStage, type ChatClause, type ChatCompactionHookDeps, type ChatConfigState, type ChatDegradeOptions, type ChatDegradeOutcome, type ChatDirectiveHandlers, type ChatDirectiveName, type ChatHelpEntry, type ChatInvokeAnswer, type ChatInvokeBinding, type ChatLanguageModel, type ChatLastTurn, type ChatModelDirectiveOutcome, type ChatReplayMessage, type ChatResolution, type ChatResolverEntry, type ChatResolverRule, type ChatResolverTable, type ChatStateContainer, type ChatStateSnapshot, type ChatTokenAccounting, type ChatToolsetFingerprint, type ChatTurnPort, type ChatTurnStateSink, type ClaimNextOptions, type ClauseAction, type ClauseSplitter, type ClauseVerdict, type ClockPort, type CompactionHook, type CompactionPass, type CompactionPassInput, type ConfigFieldSetResult, type ConfigFieldValue, type ConfigFileBytes, type ConfigFileSet, type ConfigFilesPortLike, type ConfigPathFacts, type ConfigReaderPort, type ConfigScaffoldContentPortLike, type ConfigStructuredValue, type ConfigValidatePortLike, type ConfigValidation, type ConfigValidationIssue, type CreateAgentJobQueueOptions, type CreateChatStateInput, type CreateFunctionRegistryOptions, type DraftReceiptsReadPortLike, type DraftShelfPortLike, type DraftStageOutcome, DuplicateFunctionIdError, DuplicateJobKindError, EDITOR_LIVE_URL_FUNCTION_ID, EXPLAIN_FUNCTION_ID, type EntityDirectoryPort, EntityNotFoundError, EvidenceBlobAbsentError, type EvidenceBlobReaderPort, type ExplainAbstentionRecord, type FallbackContinuationInput, type FallbackContinuationProducer, type FunctionBindingStatus, type FunctionDeclaration, type FunctionDeps, FunctionInputError, FunctionNotBoundError, type FunctionRegistry, type FunctionResultFold, type FunctionResultKind, type FunctionStream, IncompleteJobKindDeclarationError, InconsistentJobKindDeclarationError, type JobAuthorCallback, type JobBackoffPolicy, type JobCancelOutcome, JobCancellationNotRequestedError, JobCancelledError, type JobCheckpointContext, type JobCheckpointReadOutcome, type JobCheckpointRecord, type JobClaimOutcome, type JobCompleteOutcome, type JobEnqueueOutcome, type JobFailureDisposition, type JobHandler, type JobHandlerContext, type JobIdSource, type JobInsert, type JobKindDeclaration, type JobKindRegistry, type JobModelCapability, type JobModelOutput, type JobModelRequest, type JobPermanentFailureDisposition, type JobRecordedValueOutcome, type JobRequeueOutcome, type JobStoreDump, type JobStoreDumpRow, type JobStoreFence, type JobStorePort, KNOWLEDGE_GATES_LIST_FUNCTION_ID, KnowledgeGatesUnboundError, type KnowledgePort, type KnowledgeReaderPort, type KnowledgeReviewPort, LIVE_EMBED_PATH_PREFIX, LIVE_URL_TOKEN_VERSION, LIVE_URL_TTL_MS, type LiveViewPort, LiveViewUnavailableError, MARK_UNHANDLED_CEILING, type MarkUnhandledCounts, MissingIdempotencyKeyError, OPTIONAL_FUNCTION_DEP_KEYS, type OptionalFunctionDepKey, type PersistencePort, type PlannerStageFailure, type PlannerStageOutcome, type PlannerStagePort, type PlannerToolCall, type PostProcessingChainState, type PostProcessingJobRow, type PostProcessingReaderPort, type PostRunJobCapabilities, QUARANTINE_ADD_FUNCTION_ID, QUARANTINE_LIST_FUNCTION_ID, QUARANTINE_RELEASE_FUNCTION_ID, QuarantinedJobRequeueError, REAL_JOB_KIND_DECLARATIONS, RUNS_ARTIFACT_FUNCTION_ID, RUNS_DETAIL_FUNCTION_ID, RUNS_DIGEST_FUNCTION_ID, RUNS_EVENTS_FUNCTION_ID, RUNS_EVIDENCE_FUNCTION_ID, RUNS_KNOWLEDGE_FUNCTION_ID, RUNS_LIST_FUNCTION_ID, RUNS_LIVE_URL_FUNCTION_ID, RUNS_MARKS_HISTORY_FUNCTION_ID, RUNS_MARK_FUNCTION_ID, RUNS_MARK_PREVIEW_FUNCTION_ID, RUNS_OVERVIEW_FUNCTION_ID, RUNS_POST_PROCESSING_FUNCTION_ID, RUNS_START_FUNCTION_ID, type RanJobOutcomeBase, type ReconcileInput, type ReconcileStrategy, type ReconcileVerdict, type RecoverAbandonedClaimsInput, type RecoverAbandonedClaimsOutcome, type RecurrenceAnswer, type RecurrenceLadder, type RecurrenceProvider, type RecurrenceQuery, type RepairSessionOptions, type ReplayedRunEvent, type ResolvedClause, type RunDetailReaderPort, RunEndedWithoutVerdictError, type RunInvocationPort, type RunNextJobInput, type RunNextJobOutcome, RunNotFinishedError, RunNotFoundError, RunNotRecordedError, type RunsReaderPort, SCENARIO_CORPUS, SCENARIO_CORPUS_VERSION, type ScenarioCorpusEntry, type SessionLogLine, type SessionRepair, type SessionReplay, StaleJobStoreEpochError, type StandInJobScript, type StartedRun, type StepEvidenceAddress, type StepEvidenceLookup, StreamReplayFloorError, type SuiteOutcomeHistoryPortLike, type TurnEngine, type TurnEngineDeps, UndeclaredJobCheckpointError, UndeclaredJobSuccessorError, UnknownFunctionError, UnknownJobKindError, UnknownLiveEditorSessionError, UnknownRunError, authoringFanOutBound, ceilingExceeded, chainJobIdsForRun, clusterVerdicts, composeBanner, computeMarkUnhandledRate, createAgentJobQueue, createChatCompactionHook, createChatState, createFunctionRegistry, createJobKindRegistry, createPlannerStage, createRealJobKindRegistry, createTurnEngine, decodeBase64Url, deterministicOverrideStrategy, encodeBase64Url, evaluateAssertionStrength, foldFunctionResult, fromToolName, gatherSuiteStability, invokeFunction, isChatMetaToolName, liveUrlOf, maybeCompact, mintLiveUrlToken, parseScenario, projectAuthoringFunnel, projectPlannerTools, recordLlmAuthorship, renderAnalysisClusterBlock, renderVerdictSentence, repairSession, replaySession, replayToModelMessages, resolveClause, runAuthoringLoop, scenarioRelativePath, scopeReceiptsToWindow, splitClauses, unhandledReason, validateLiveUrlToken };