Repository-Aware Brainstorm Suggestions - Plan

Overview

Add an advisory second pass after Hive publishes a brainstorm round. It produces one independently bound suggestion per unanswered question from a bounded tracked-only repository/wiki snapshot and durable operator answers. A task-local sidecar is canonical; TUI comments and Web cards are non-authoritative projections. Every worker route must run inside an enforceable data-only sandbox, and persisted advisory state must be removed when brainstorm ownership ends or before downgrade.

Goal Capsule

• Objective: Give operators repository-aware help without making suggestions part of answer or workflow authority.
• Means: Publish questions first, capture bounded evidence, run isolated daemon-owned workers, validate into canonical state, and project only current candidates.
• Authority: Only explicit final submission from the TUI or Web Send answers may invoke existing answer writers. Delimiter removal and editor saves prepare drafts; they are not submission.
• Stop conditions: Never expose actionable text from a stale, partial, unsafe, malformed, falsely attributed, or unbound result. Manual answering remains available in every state.
• Tail ownership: Deliver locally verified code, full coverage for new library branches, managed-wiki updates, runtime cleanup, and a documented downgrade procedure; no release or deployment.

Requirements Trace

Scope Boundaries

Implement the complete curated suggestion lifecycle in this task. Reuse existing task locks, runtime dispatch, answer writers, secret screening and Web answer submission seams; proposed suggestion modules are additions, not claims that those files already exist.

Telegram and Guided/YOLO keep their current answer behavior. No automatic answer selection, submission, final requirements generation, workflow advancement, general recommendation framework, release, deployment or version change is included. TUI draft staging and explicit submission are limited to the suggestion-enabled editor flow; do not rewrite unrelated answering flows.

No known external prerequisite is declared in authoritative meta.yml; no scheduling dependency is invented. U1-U7 dependencies are internal implementation order. This stage modifies only plan.md and runs no project code or tests. Documentation and verification below belong to execution.

Repository Grounding

• lib/hive/brainstorm_parser.rb is shared by daemon and bot, and recognizes hive-answer:v1 encoding. Encoding is not proof of human authorship; suggestion context needs explicit trusted writer provenance or conservative exclusion.
• lib/hive/tui/brainstorm_answers.rb has its own completeness predicate. It strips HTML comments from answer bodies, but structure recognition must also ignore whole suggestion regions before examining headings.
• templates/brainstorm_prompt.md.erb and lib/hive/stages/brainstorm.rb own first-pass production. Prompt instructions alone cannot prove model behavior; controller-side admission must prevent an untouched comment from becoming completion evidence.
• lib/hive/daemon/{dispatcher,child_supervisor}.rb provide ancillary scheduling seams. web/app/controllers/tasks/answers_controller.rb, web/app/models/task.rb, and web/app/javascript/controllers/answers_controller.js are existing Web answer seams.
• wiki/index.md and wiki/stages/brainstorm.md describe marker-driven rounds and first-pass constraints. .llm-wiki/config.json currently has no main wiki path; configured-main-wiki support must still be covered by fixtures.
• AGENTS.md makes exhaustive coverage a CI gate, with local runs reserved for coverage machinery changes or explicit requests.

Product Contract

Requirements

• R1 — asynchronous lifecycle: Publish normal questions before scheduling suggestions. Reconcile every unanswered question in every active waiting round, including pre-feature and crash-window rounds, and create missing records. Generation never blocks manual submission.
• R2 — eligible evidence: Use the task request, committed tracked blobs overlaid with tracked staged/unstaged changes and deletions, bounded tracked project-wiki files, and an optional validated main wiki. Ignore untracked/ignored files. Bind only selected path/mode/content digests and the selection recipe/version; repository-global HEAD is descriptive diagnostics only and is not part of freshness.
• R3 — settled context: Include all operator-written answers durably persisted in brainstorm.md, including answers already saved in the current round regardless of slot number. Exclude drafts, envelopes, candidates, and agent defaults. Unknown authorship is not silently classified as operator-written.
• R4 — candidate safety: A fresh candidate is valid UTF-8, at most 1,000 characters and 12 lines, contains no fenced block or unsafe structure/markup/control/prompt/secret material, has a short rationale, and carries provenance derived by the controller from sources actually present in the bound manifest. Unsafe or weak evidence yields a bounded static non-actionable reason.
• R5 — freshness: Bind task incarnation/generation, brainstorm generation, question identity/text, selected evidence digests, and settled answers. A changed binding immediately hides old text. Automatic regeneration is coalesced and rate-limited per task/input epoch; repeated repository activity cannot create an unbounded provider loop.
• R6 — TUI: Insert one exact removable hive-suggestion:v1 HTML-comment envelope after its answer heading. The first-pass brainstorm prompt, Ruby parsers, TUI completeness logic, and answer writer all treat the whole reserved region as advisory, never as an answer. Removing delimiters adopts only the body; deleting the exact envelope dismisses that candidate. TUI offers Restore/Retry for a dismissed current candidate.
• R7 — Web: Show the same candidate with reversible Approve/Undo and Decline/Restore. These controls modify browser presentation only; Send answers alone writes answers.
• R8 — shared projection: hive answer --json exposes bounded state, current text/rationale/provenance, safe reason, retryability, and binding identity. Telegram and Guided/YOLO behavior remain unchanged.
• R9 — documentation: Document lifecycle, isolation, cleanup/downgrade, provenance, regeneration bounds, surfaces, authority, and verification in the managed wiki plus one log fragment.
• R10 — non-authority: Generation, display, persistence, refresh, Retry, Restore, Approve, Decline, or envelope preservation cannot create a parsed answer, completion marker, auto-resume, stage transition, or workflow dispatch.

Acceptance Examples

• AE1 Advisory isolation: Across every advisory state/action, parsed answers, markers, attempt/dispatch authority, task stage, and workflow state remain unchanged.
• AE2 Stale/degraded behavior: Input change, unavailable isolation/route, or attempt failure synchronously removes text from all projections, shows bounded state/retryability, and leaves manual submission enabled.
• AE3 Context/output safety: Ineligible paths, secrets, unsafe markup, prompt control, false provenance, partial capture, or an unenforceable worker route never become actionable or enter logs/state as raw material.
• AE4 Presentation parity: For one suggestion binding, TUI adoption and Web approval yield byte-identical editable bodies while JSON reports the same server state.
• AE5 First-pass inertness: Rerunning the brainstorm producer on an unanswered round containing an untouched envelope cannot admit final Requirements or a COMPLETE marker and preserves the unanswered slot.
• AE6 Lifecycle cleanup: Answering a question or leaving 2-brainstorm cancels its work and removes actionable sidecar/envelope text; downgrade cleanup makes artifacts safe for an old parser before disabling/reverting the feature.

Planning Contract

Fixed technical decisions

The selected-digest strategy below retains the existing plan's interpretation of relevant repository state: capture from committed HEAD plus tracked edits, and invalidate when eligible selection or selected bytes change. A new unrelated commit need not invalidate identical relevant evidence. HEAD/index changes must still trigger selection re-evaluation, including newly relevant tracked files; selected-file-only watching is insufficient.

1. brainstorm-suggestions.json at the active task root is the owner-private canonical runtime store; it contains no raw context or unvalidated output.
2. input_binding excludes repository-global HEAD; it hashes the exact selected manifest. suggestion_binding adds immutable attempt/candidate identity.
3. Capture/select evidence outside the task lock. Under the lock, cheaply recheck task/question/answer generation and CAS the sidecar. Re-observe the external selected manifest afterward; discard/retry if it changed.
4. The daemon scheduler reconciles active waiting rounds, not just publication events. Missing records are first-class work.
5. A worker is available only when its configured provider profile can enforce: bundle-only readable filesystem, no live repository/task mounts, no shell tools, no network tools, and one controller-owned structured result channel. Merely changing cwd or file mode is insufficient. Profiles that cannot prove this policy yield unavailable and are never launched.
6. Temporary bundle roots are mode 0700, files are owner-readable only, bundle content is immutable to the worker, and the controller unconditionally removes each bundle after success, failure, timeout, TERM/KILL, or spawn error. Daemon startup sweeps inactive owned bundle roots.
7. The controller derives source labels from the admitted bound manifest; the model does not choose provenance. If labels remain in provider output for compatibility, validation requires a nonempty subset of present manifest classes and replaces them with controller-derived labels.
8. Retry is allowed from failed, unavailable, no_safe_suggestion, and a dismissed fresh candidate. An active identical request remains idempotent. TUI exposes Restore/Retry so accidental deletion is recoverable without unrelated input churn.
9. On answer persistence, question removal, task move, or departure from 2-brainstorm, transition-locked cleanup cancels workers and deletes the sidecar/envelopes, or leaves only a bounded non-actionable tombstone needed for late-result fencing. Later-stage context, supporting artifacts, state commits, and archives cannot retain actionable suggestion text.
10. Before feature disable/revert/downgrade, run a documented idempotent cleanup command that strips all reserved envelopes and actionable suggestion sidecars under exact task locks, verifies parser-visible answers are unchanged, and emits a bounded receipt. The feature flag cannot be disabled while cleanup reports unsafe artifacts.

Admission and presentation details

• Bind the exact task request digest as well as task incarnation/generation. A request edit invalidates candidates even if no generation counter changed. Use stable question identity plus exact normalized-newline question bytes; do not substitute the answer command's looser display fingerprint for exact suggestion freshness.
• Validate UTF-8 before counting Unicode code points and LF-normalized lines. Bound the complete displayed candidate (answer plus rationale) to 1,000 characters and 12 lines, with a separate byte ceiling for input parsing. Use a closed source-class vocabulary and bounded static reason codes. TUI and Web adopt only the same answer field; rationale remains advisory metadata. Reject comment delimiters, structural headings, fences and prompt-control material in the answer field. Web renders plain text through safe text APIs, never raw HTML.
• The envelope's opening delimiter line identifies version and binding; its closing delimiter line ends the envelope. Removing those two lines leaves exactly the answer field. Rationale and source labels appear outside the editable answer body in TUI chrome, using the shared sidecar contract. Deleting the whole envelope declines only that candidate. This avoids adopting identifiers or rationale as answer text.
• A provider connection is controller-owned transport, not a worker network tool. Permit only the configured provider transport and required runtime files; expose no repository, task storage, ambient credentials or arbitrary network/tool capability to model-directed execution. Do not call a prompt-only permission restriction an enforced sandbox.
• After a compare-and-swap result write, keep the record non-actionable until post-capture observation succeeds. Shared projection revalidates before returning text; failed observation returns null text. Web approval performs a read-only binding refresh before copying; broadcasts invalidate visible controls on observed changes. An idle browser or disconnected editor cannot observe arbitrary filesystem edits instantaneously, so reconnect/approval/submission must revalidate, and offline approval is disabled. Manual text entry remains usable.

High-Level Technical Design

The existing runtime and locks determine exact implementation placement; these sketches specify authority and data flow.

First-pass publisher -> unanswered round -> auxiliary scheduler
Task/repository/wiki/settled answers -> bounded context -> isolated provider
Provider result -> validator + binding recheck -> canonical sidecar
Sidecar -> shared read-only projection -> TUI draft / Web draft
Operator explicit submission -> existing answer writer -> normal workflow

Observe eligible inputs outside lock -> capture immutable bundle
Lock: compare task/question/answer identity -> reserve attempt -> unlock
Run provider -> validate -> lock: compare attempt and owner -> unlock
Reobserve external manifest -> admit fresh, or discard and coalesce retry

Current binding? no -> stale, null text, schedule bounded regeneration
Supported isolated route? no -> unavailable, manual answers enabled
Safe sufficient evidence/output? no -> no_safe_suggestion, null text
Fresh admitted result? yes -> display; adoption/approval changes draft only
Explicit operator submission? yes -> writer rechecks question and ownership

The lifecycle diagram below specifies terminal/degraded states. The shared machine object contains schema version, question identity, state, nullable answer/rationale, bounded source classes, reason code, retryability, input binding and candidate binding. No read operation schedules or submits work; reconciliation is daemon-owned and Retry is an explicit advisory mutation.

Canonical lifecycle

stateDiagram-v2
  [*] --> loading: scheduler finds unanswered question or missing record
  loading --> fresh: current admitted candidate
  loading --> no_safe_suggestion: weak/conflicting/suppressed
  loading --> unavailable: isolation, route, or context unavailable
  loading --> failed: timeout/provider/malformed result
  fresh --> stale: selected binding changes
  no_safe_suggestion --> stale: selected binding changes
  unavailable --> stale: selected binding changes
  failed --> stale: selected binding changes
  stale --> loading: coalesced rate-limited regeneration
  failed --> loading: Retry
  unavailable --> loading: Retry
  no_safe_suggestion --> loading: Retry
  fresh --> loading: Retry dismissed candidate
  loading --> [*]: answered, removed, or stage exited
  fresh --> [*]: answered, removed, or stage exited

Only fresh exposes text. Projection distinguishes “missing record awaiting reconciliation” as loading, never as an absent card. Automatic regeneration uses one active request per question/input binding, a task-level coalescing window, minimum retry interval, bounded attempts per input epoch, and jittered backoff. A new input epoch resets that budget; ordinary task-folder commits or unrelated Git commits do not.

Output structure

lib/hive/brainstorm_suggestions.rb
lib/hive/brainstorm_suggestions/{binding,context_bundle,envelope,runner,store,validator}.rb
lib/hive/daemon/brainstorm_suggestion_scheduler.rb
lib/hive/commands/brainstorm_suggestion.rb
templates/brainstorm_suggestion_prompt.md.erb
templates/brainstorm_prompt.md.erb
schemas/hive-answer.v1.json

Implementation Units

U1. Canonical domain, inert grammar, and downgrade cleanup

• Goal: Establish bounded state, bindings, envelope grammar, parser/prompt inertness, terminal cleanup, and downgrade safety before generation.
• Requirements: R3, R5, R6, R8, R10; AE1, AE5, AE6.
• Files: lib/hive/brainstorm_suggestions.rb, lib/hive/brainstorm_suggestions/{binding,store,envelope}.rb, lib/hive/brainstorm_parser.rb, lib/hive/tui/brainstorm_answers.rb, lib/hive/bot/brainstorm_answer_writer.rb, templates/brainstorm_prompt.md.erb, lib/hive/commands/brainstorm_suggestion.rb, related unit tests.
• Approach:
  1. Define closed records and strict owner-private, no-follow, bounded atomic storage. Treat malformed reserved regions as inert/corrupt advisory material without hiding operator text outside them.
  2. Implement input/suggestion bindings using selected content identities, not HEAD.
  3. Make the shared parser, TUI completeness parser, writer, and first-pass prompt explicitly skip hive-suggestion:v1 regions before recognizing Markdown structure. Tell the brainstorm agent that content inside them is never a filled answer. Gate final-artifact admission on the controller's pre-launch durable operator-answer snapshot, so a producer cannot fabricate answers from comments or emit accepted completion on their authority.
  4. Make answer writers replace an envelope as an empty slot under existing locks.
  5. Implement exact-stage cleanup on answer/task transition and an idempotent pre-disable cleanup/verification command. Preserve parsed operator answers byte-for-byte.
• Test scenarios: Unit cases cover valid/malformed/nested/breakout envelopes, delimiter-only adoption, full deletion, old-parser cleanup fixtures, and prompt contract text. Store corruption never exposes text. Trusted human and agent-default writer fixtures prove identical encoding does not imply identical authorship.
• Verification: Run focused parser, TUI completeness, writer, envelope and store tests; compare answers, completion and dispatch state before/after each advisory operation.

U2. Deterministic context, enforceable worker isolation, and admission

• Goal: Build bounded eligible evidence and admit only safe, correctly attributed results from enforceably isolated workers.
• Requirements: R2-R5, R10; AE2, AE3.
• Dependencies: U1.
• Files: lib/hive/brainstorm_suggestions/{context_bundle,validator,runner}.rb, repository/wiki provenance helpers, lib/hive/{secret_patterns,config,model_routing}.rb, lib/hive/agent_profile.rb, built-in profile definitions, both brainstorm prompts, project config template, focused unit/integration tests.
• Approach:
  1. Enumerate Git-index eligibility and stable no-follow bytes; reject conflicts, submodules, unsafe symlinks, special files, and descriptor races.
  2. Deterministically select relevant tracked content. Manifest recipe/version and selected path/mode/content digests plus validated selected main-wiki digests form freshness. Record HEAD only as non-binding diagnostics.
  3. Include task request and all durable operator answers; screen secrets before provider transfer and wrap excerpts as untrusted data. Track controller-authorized writer provenance bound to exact answer bytes; unproven legacy text is excluded with a bounded explanation, never inferred from hive-answer:v1 alone.
  4. Add a capability check and managed launch policy for every configured provider profile. Launch only profiles that enforce bundle-only reads, no live mounts, no shell/network tools, and controller-only output. Classify all others unavailable.
  5. Create bundles under controller-owned 0700 roots, set restrictive file modes, and unconditionally delete them in an ensure/finalization path covering spawn, timeout, process-group kill, and validation failures. Sweep inactive owned roots on daemon startup.
  6. Validate disposition/text/rationale. Derive nonempty provenance labels from manifest source classes actually selected; reject absent-source and hallucinated-label claims.
• Test scenarios: Provider-profile isolation tests attempt live repository/task reads, shell execution, network access, alternate outputs, and path escape for every supported route. Tests also cover exact size/line boundaries, unsafe output, absent/conflicting sources, bundle permissions, kill-path cleanup, and startup sweep. Include a later-numbered durable answer, tracked addition/deletion/rename, newly relevant files and main-wiki changes.
• Verification: Run focused context/runner/validator tests plus supported-route isolation integration tests. At least one actual configured route must demonstrate a fresh admitted suggestion; unsupported routes degrading successfully is not proof that generation works.

U3. Durable scheduler, two-phase publication, and bounded regeneration

• Goal: Reconcile all active unanswered questions and run bounded auxiliary work without holding task locks during capture.
• Requirements: R1, R5, R8, R10; AE1, AE2, AE6.
• Dependencies: U1, U2.
• Files: lib/hive/stages/{brainstorm,base}.rb, lib/hive/daemon/{dispatcher,child_supervisor,brainstorm_suggestion_scheduler}.rb, lib/hive/commands/brainstorm_suggestion.rb, CLI registration and tests for these seams. The suggestion scheduler and command are new.
• Approach:
  1. Publication may eagerly seed records, but each daemon poll inventories active waiting rounds and creates missing records for every unanswered question. This closes rollout and publication-crash gaps.
  2. Observe/select/capture outside the task lock with a deadline. Acquire the lock only to re-resolve task/stage/question/answer generation and CAS a request/result. Re-observe the external selected manifest after lock release; discard/coalesce if it changed.
  3. Coalesce one request per binding and enforce concurrency, per-question/task minimum intervals, bounded automatic attempts per input epoch, backoff, and jitter. Retry creates a new suggestion binding only where the lifecycle permits.
  4. Dispatch token-bound isolated ancillary children. Late completion cannot recreate folders or beat an operator answer/newer attempt.
  5. Reconcile orphan loading records and missing records after restart; sweep orphan bundles; classify unavailable isolation separately from failed attempts.
  6. Under the transition lock, cancel work and remove actionable state when a question is answered or the task leaves brainstorm.
• Test scenarios: Preexisting WAITING rounds without records, crash between publication and seeding, slow capture concurrent with an answer writer, commit storms, unrelated commits, Hive marker commits, restart, late exits, terminal cleanup, and bounded provider-call counts.
• Verification: Run focused daemon, stage and auxiliary worker integration tests; assert suggestion work never invokes stage dispatch or holds the task lock during external capture/provider calls.

U4. TUI projection and recovery

• Goal: Preserve external-editor ownership while making dismissal reversible.
• Dependencies: U1, U3.
• Files: lib/hive/tui/{update,bubble_model,messages,key_map,brainstorm_answers}.rb, editor takeover handlers and focused unit/E2E tests.
• Approach: Project only current non-dismissed envelopes under a short task-local lease; workers remain sidecar-only. Compare the exact pre-open envelope after editor exit to distinguish adoption, dismissal, and untouched state. Never insert a newer candidate into an old saved buffer. Add Restore for a dismissed current candidate and Retry-from-fresh to request a new candidate; both are advisory.
• Approach — draft authority: Open a task/question-bound temporary editor draft for the suggestion-enabled flow. Removing the envelope's opening and closing delimiter lines leaves only the editable answer body; binding/version metadata belongs on delimiter lines or in the sidecar, never in adopted text. Saving that draft cannot update canonical answers or trigger auto-resume. The TUI explicitly submits the saved answers through the existing locked writer; revalidate question identity and stale candidate origin first. A stale adopted draft remains editable but requires explicit confirmation as manual text before final submission. Workers never rewrite an open editor buffer.
• Test scenarios: Editor races, reruns, accidental deletion/restore, retry from fresh/no-safe, stale projections, and reopen-after-loading preserve answer/completion authority. Saving an adopted last answer does not resume; explicit submission does. Cancel and crash preserve canonical answers.
• Verification: Run focused TUI/editor integration tests with before/after canonical artifact and dispatch snapshots; prove exact fresh body parity with Web approval.

U5. Shared JSON/Web projection with bounded freshness observation

• Goal: Expose one read-only contract and reversible Web presentation without turning Web renders into repository scans.
• Dependencies: U1, U3.
• Files: lib/hive/commands/answer.rb, schemas/hive-answer.v1.json, web/app/models/task.rb, web/app/controllers/tasks/answers_controller.rb, web/app/javascript/controllers/answers_controller.js, task question partials, Web routes, status broadcaster and Web tests.
• Approach:
  1. Add the nested suggestion object while leaving mutation/readiness schemas unchanged.
  2. Compute one deadline-bounded freshness observation per task/read transaction, shared across all slots. Reuse across consumers only with a proven current observation identity covering eligible selection, Git index/worktree content, wiki state, task request/generation and settled answers. Any uncertain identity requires re-observation; timestamps alone are insufficient. Observation failure returns null text and bounded stale/unavailable state.
  3. Keep answer drafts answer-bound and card state suggestion-bound in bounded browser/session maps. Approve/Decline/Undo/Restore are client-only. Retry is binding-checked and queues work only.
• Test scenarios: Multi-question/task scale, deadlines, cache invalidation, no scans per slot, null text on observation failure, Turbo/reload behavior, HTML escaping, and Send answers as sole answer mutation. Approve/Undo restores the previous draft; Decline/Restore resets only when suggestion binding changes. Invalidated approval drafts remain editable, but stale candidate origin requires explicit manual confirmation before Send.
• Verification: Run answer JSON schema tests, Web model/request/system tests, and count freshness observations per shared read transaction. One bounded task observation may be required per request; no mtime-only cache may assert current content after an unobserved external write. Retry uses existing authentication/CSRF policy and validates exact current binding without changing answers.

U6. Cross-surface authority, compatibility, race, and cleanup proof

• Goal: Exercise real producers/consumers and prove advisory behavior cannot acquire authority or survive its ownership boundary.
• Dependencies: U3-U5.
• Files: real brainstorm integration, answer-skill/bot/daemon/task tests, Web integration/system tests, provider-profile isolation integration fixtures.
• Approach and scenarios:
  1. Capture parsed answers, markers, stage, durable attempts, dispatches, and artifacts before every advisory action and assert no authority signal changes.
  2. Rerun the first-pass controller with producer fixtures that preserve envelopes and fixtures that deliberately manufacture answers/Requirements from them. Assert no admitted final artifact, COMPLETE marker or auto-resume without pre-existing operator-submitted answers. A live-provider smoke supplements this deterministic authority proof; it cannot prove all future model output.
  3. Exercise concurrent generation, slow capture, answer persistence, repository/wiki changes, editor ownership, Web refresh, daemon restart, task moves, and commit storms.
  4. Prove profile isolation for each provider and fail closed for unsupported profiles.
  5. Prove answer/task transitions cancel work and prevent actionable suggestion text from entering moved folders, state commits, supporting artifacts, later-stage agent context, or archives.
  6. Run the downgrade command on persisted envelope/sidecar fixtures and then parse with the pre-feature parser fixture; answers/completion match the pre-suggestion artifact.
  7. Preserve existing Telegram and Guided/YOLO fixtures byte-for-byte.
• Test scenarios: The seven cases above form the cross-surface matrix; include manual submission from every degraded state and provider success while an operator submits concurrently.
• Verification: Run focused integration and Web system suites, followed once by the broad Ruby suite and RuboCop. Keep exhaustive coverage in CI under the repository policy.

U7. Documentation

• Goal: Document the implemented lifecycle and operational boundaries.
• Dependencies: U1-U6.
• Files: wiki/stages/brainstorm.md, answer/TUI/Web/daemon command pages, daemon/agent/model-routing/secret modules, CLI/testing/gaps as needed, and wiki/log.d/<timestamp>-repository-aware-brainstorm-suggestions.md.
• Approach: Document eligible evidence, selected-digest freshness, managed sandbox requirements, unavailable routes, provenance derivation, bundle permissions/cleanup, scheduler coalescing/rate limits, missing-record reconciliation, TUI Restore/Retry, stage-boundary deletion, and the mandatory pre-disable downgrade procedure. Do not edit compiled wiki/log.md.
• Test scenarios: Walk the documented loading, approval/adoption, decline/restore, stale/retry, no-safe-suggestion and final-submission examples against the implemented surfaces. Documentation needs no separate executable tests.
• Verification: Review affected managed pages against the shared schema and tested lifecycle; verify one new wiki log fragment and no direct compiled-log edit.

Verification Contract

Packaged Web bootstrap, TUI reactivity scale, multi-agent integration, and babysitter security matrices remain CI-only unless their machinery is changed or a focused failure requires diagnosis.

Risks

Definition of Done

• AE1-AE6 pass through real parser, first-pass producer, daemon, TUI, Web, and answer-authority seams.
• All active unanswered waiting rounds acquire observable records, including rollout/crash-window tasks.
• Only current validated fresh records expose text, with controller-derived provenance from selected evidence.
• Every launched provider profile proves the managed data-only sandbox; unenforceable profiles are unavailable.
• Capture does not hold the task lock, Web/JSON reads share bounded freshness observations, and automatic regeneration is coalesced/rate-bounded.
• TUI dismissal is reversible; all advisory actions remain non-authoritative.
• Answer/task transitions remove actionable advisory state, runtime bundles are always cleaned, and downgrade cleanup makes persisted artifacts safe for the old parser.
• Focused tests, Web tests, bundle exec rake test and RuboCop pass locally; the exhaustive coverage gate passes in CI. No checks are claimed to have run during this planning stage.
• Managed wiki pages and one log fragment are updated; compiled wiki/log.md is untouched.
• No release, deployment, publication, version change, or unrelated cleanup is included.

Planning Review and Handoff

Confidence check: repository seams, origin trace, unit verification, authority, stale-result admission and scope were checked by static inspection. No blocking product question remains. The new modules and supported-route isolation are implementation work, not existing capabilities claimed as verified.

Formal ce-doc-review did not run: this host exposes no separate skill-invocation primitive, and the planning handoff forbids substituting a generic agent for that invocation. Structured review state: fixes_applied: 0, proposed_fixes_count: 0, decisions_count: 0, fyi_count: 0, skipped_reason: skill_unreachable. This is not an independent review pass. Hive's existing native plan-review state remains authoritative and untouched; this completion marker completes authoring only and does not grant execution approval.

No implementation, tests, native review retry, metadata change, context receipt, release or deployment was performed. The only edited artifact is this plan.