context-manifest

/context-manifest - Route context reads

This is optional context routing. It is not a workflow gate, source summary, durable artifact, or substitute for source-of-truth reading.

<input_contract> Resolve from $ARGUMENTS:

• target workflow or work type;
• one FT-*, TASK-*, or REQ-* target, or a short free-form goal;
• optional downstream read budget;
• whether codebase/test evidence is needed.

Before discovery, read local AGENTS.md, .memory-bank/roles/explorer.md, and, when a target workflow exists, its installed skill. Resolve IDs through existing indexes/registries. Do not invent a separate CLI parser.

The caller should delegate this work only when broad discovery is likely to cost more context than a separate Explorer call. Direct reads are normally cheaper for simple T0/T1 work or a small task with an obvious complete read set. </input_contract>

<hard_invariants>

• Work read-only. Do not execute the target workflow, edit files, create planning/spec/task/protocol artifacts, or launch subagents.
• Return routes, not source contents. No file dumps, long summaries, product or design conclusions, secrets, credentials, or environment values.
• Direct canonical links outrank registry-only guesses. Do not route one concern to competing active specs or use archive/legacy material as current authority without an explicit active-source reason.
• Workflow-mandatory files remain read_full; never shorten them for budget.
• The manifest is an initial read set, not a scope boundary. The caller expands it when read sources, direct links, diff, or evidence require more context.
• Do not persist the manifest in .memory-bank/, .protocols/, or .tasks/.
• Do not change target workflow inputs, outputs, gates, statuses, ownership, or handoff contracts. </hard_invariants>

<operator_decisions> Explorer does not resolve product, acceptance, architecture, contract, storage/state, security, tier, task-boundary, dependency, or verification ambiguity.

Record every unresolved branch or competing canonical route under Gaps / stop conditions. When the operator can decide it, the caller must interview the operator under the owning workflow before proceeding. A recommendation, default, or silence is not acceptance. </operator_decisions>

<agent_discretion> Within the read-only boundary, choose the search order, tools, discovery depth, focused ranges, anchors, and optional sources that produce the smallest sufficient manifest. Prefer indexes, direct links, targeted search, and current-worktree evidence over broad reads. </agent_discretion>

<routing_profiles>

• Planning/design: include governing priming, target feature/epic/REQ/RTM, backbone/index, plausible subject-based canonical specs, existing plans/tasks, and only necessary codebase evidence.
• Execute: include indexed task record, tier policy, direct task-linked specs, minimal feature/REQ context, and relevant code/tests. Do not add broad Constitution/backbone/index context for T0/T1 without a direct reason.
• Verify/review: include target record/plan, acceptance basis, direct specs, implementation diff/evidence, applicable testing contracts, and only needed upstream context. The verifier may expand beyond the manifest independently.
• Broad analysis: start from governing routers/indexes, then include only evidenced relevant Memory Bank areas and codebase seams.

Follow source_artifacts, normative_inputs, spec_design_links, task, feature, and REQ links. For T2/T3 execution or verification, the indexed task card and direct task-linked canonical specs are mandatory; feature links are only composition/drift context. Exclude archive, legacy, and background areas unless a current source needs them as evidence. </routing_profiles>

<required_outputs> Return only this final shape; omit empty optional sections except Gaps / stop conditions: