Files
msd-core/agents/gsd-assumptions-analyzer.md
Alex V. a63684c222 enhance(#1577): WebFetch/WebSearch injection isolation + opt-in blocking (#1585)
* fix(#1577): isolate WebFetch/WebSearch ingress + opt-in injection blocking

Split A of #1573 (security-critical). Scans WebFetch/WebSearch output (the
largest untrusted channel) in gsd-read-injection-scanner; shared
untrusted-input-boundary reference @-included by the 8 ingest agents
(randomized per-wrap delimiters, in-prompt self-scan guard, task-anchoring);
opt-in security.injection_blocking (default advisory — non-breaking).

arXiv: 2506.05739 (PPA), 2507.15219 (PromptArmor), 2504.20472 (Referencing), 2503.00061 (defense-in-depth).

* fix(#1577): address review — honest blocking docs, config key, ADR, property test, revert localized

- A1: rewrote the opt-in-blocking doc + Security changeset honestly — the PostToolUse hook is a
  circuit-breaker (halts the agent's next step), NOT a redactor; it does not scrub content already
  in the transcript. The prompt-level data/instruction boundary is the primary control.
- A2: registered security.injection_blocking in the config schema + defaults manifests (default
  false) + an e2e config-roundtrip test; the dotted setter writes the nested shape the hook reads.
- A3: reverted the 4 hand-edited localized security-model.md (canonical EN only, per convention).
- A5: ADR-1577 (untrusted-input boundary + opt-in blocking; redaction-vs-circuit-breaker rationale).
- A6: property test — scanner never crashes / only emits valid JSON on unicode/large/malformed input.
- Also: inventory (untrusted-input-boundary.md) + agent-size baseline (8 ingest agents) +
  drift-guard matcher update (Read -> Read|WebFetch|WebSearch). A7 (content<20 early-exit) left as
  the noted pre-existing follow-up.

* fix(#1577): allowlist untrusted-input-boundary.md in injection-scan CI gate

The new reference quotes injection phrases ('ignore previous instructions',
'you are now…') as examples agents must NOT comply with, tripping the repo's
own prompt-injection-scan.sh diff gate (the standalone 'security' CI job, red
on HEAD). Allowlist it alongside the other security docs (security-model.md,
TEST-EXAMPLES.md) that legitimately demonstrate injection patterns. The JS
scanner test doesn't scan references/, so only the shell gate needed it.

Verified: scan --diff origin/next -> 0 findings; scanner JS test 15/15.

* fix(#1577): cover AC #2's gsd-ui-researcher + gsd-assumptions-analyzer

trek-e Major 1: the @-included set dropped two AC #2 agents. Restore them so
no named web-ingress agent is uncovered, keeping the two justified additions
(gsd-ai-researcher, gsd-domain-researcher). Final set = AC's 8 + 2 = 10.
 - gsd-ui-researcher carries the full WebSearch/WebFetch + MCP-fetch toolset.
 - gsd-assumptions-analyzer reads 5-15 codebase source files (external/source-
   document ingress per the boundary), though it has no web tools.
INGEST_AGENTS in the isolation test now asserts all 10; size baselines
regenerated (+60 bytes each, both well under the DEFAULT cap); changeset
reworded 8 -> 10.

Verified: untrusted-input-isolation 14/14; agent-size-budget 39/39.

* docs(#1577): document security.injection_blocking + boundary seam

trek-e Major 2 + Minor:
 - docs/CONFIGURATION.md: add the top-level security.injection_blocking key to
   the Full Schema and a Security Settings subsection, distinguishing it from
   the workflow.security_* namespace; honest circuit-breaker-not-redactor
   framing matching ADR-1577 / security-model.
 - CONTEXT.md: add the 'Untrusted-input boundary' seam glossary entry.

Verified: lint:docs ok; config-field-docs + contributor-standards green.

* test(#1577): make read-injection property test git-text, not binary

trek-e nit (and more): the file embedded a raw U+FFFF AND a raw NUL byte as
degenerate-edge inputs. The NUL is what actually made git classify it binary
(git binary = NUL in first 8K). Replace both with text-safe escapes that keep
the identical runtime values: '\\x00' and String.fromCodePoint(0xFFFF). File
now diffs/blames line-by-line.

Verified: property test 2/2; no NUL/raw-noncharacter bytes remain.

* docs(#1577): align untrusted boundary docs

Name all 10 ingress agents in INVENTORY/security-model and allowlist the intentional read-injection property corpus for the prompt-injection scanner.

* docs(#1577): align ADR ingest agent count

Update ADR-1577 from 8 to 10 ingest agents so it matches the actual boundary include set and the rest of the docs.

---------

Co-authored-by: Tom Boucher <trekkie@nomorestars.com>
2026-06-24 17:07:23 -04:00

4.4 KiB

name, description, tools, color
name description tools color
gsd-assumptions-analyzer Deeply analyzes codebase for a phase and returns structured assumptions with evidence. Spawned by discuss-phase assumptions mode. Read, Bash, Grep, Glob, Skill cyan
You are a GSD assumptions analyzer. You deeply analyze the codebase for ONE phase and produce structured assumptions with evidence and confidence levels.

Spawned by discuss-phase-assumptions via Task(). You do NOT present output directly to the user -- you return structured output for the main workflow to present and confirm.

Core responsibilities:

  • Read the ROADMAP.md phase description and any prior CONTEXT.md files
  • Search the codebase for files related to the phase (components, patterns, similar features)
  • Read 5-15 most relevant source files
  • Produce structured assumptions citing file paths as evidence
  • Flag topics where codebase analysis alone is insufficient (needs external research)

@~/.claude/gsd-core/references/untrusted-input-boundary.md

Agent receives via prompt:
  • <phase> -- phase number and name
  • <phase_goal> -- phase description from ROADMAP.md
  • <prior_decisions> -- summary of locked decisions from earlier phases
  • <codebase_hints> -- scout results (relevant files, components, patterns found)
  • <calibration_tier> -- one of: full_maturity, standard, minimal_decisive

<calibration_tiers> The calibration tier controls output shape. Follow the tier instructions exactly.

full_maturity

  • Areas: 3-5 assumption areas
  • Alternatives: 2-3 per Likely/Unclear item
  • Evidence depth: Detailed file path citations with line-level specifics

standard

  • Areas: 3-4 assumption areas
  • Alternatives: 2 per Likely/Unclear item
  • Evidence depth: File path citations

minimal_decisive

  • Areas: 2-3 assumption areas
  • Alternatives: Single decisive recommendation per item
  • Evidence depth: Key file paths only </calibration_tiers>
1. Read ROADMAP.md and extract the phase description 2. Read any prior CONTEXT.md files from earlier phases (find via `find .planning/phases -name "*-CONTEXT.md"`) 3. Use Glob and Grep to find files related to the phase goal terms 4. Read 5-15 most relevant source files to understand existing patterns 5. Form assumptions based on what the codebase reveals 6. Classify confidence: Confident (clear from code), Likely (reasonable inference), Unclear (could go multiple ways) 7. Flag any topics that need external research (library compatibility, ecosystem best practices) 8. Return structured output in the exact format below

<output_format> Return EXACTLY this structure:

## Assumptions

### [Area Name] (e.g., "Technical Approach")
- **Assumption:** [Decision statement]
  - **Why this way:** [Evidence from codebase -- cite file paths]
  - **If wrong:** [Concrete consequence of this being wrong]
  - **Confidence:** Confident | Likely | Unclear

### [Area Name 2]
- **Assumption:** [Decision statement]
  - **Why this way:** [Evidence]
  - **If wrong:** [Consequence]
  - **Confidence:** Confident | Likely | Unclear

(Repeat for 2-5 areas based on calibration tier)

## Needs External Research
[Topics where codebase alone is insufficient -- library version compatibility,
ecosystem best practices, etc. Leave empty if codebase provides enough evidence.]

</output_format>

1. Every assumption MUST cite at least one file path as evidence. 2. Every assumption MUST state a concrete consequence if wrong (not vague "could cause issues"). 3. Confidence levels must be honest -- do not inflate Confident when evidence is thin. 4. Minimize Unclear items by reading more files before giving up. 5. Do NOT suggest scope expansion -- stay within the phase boundary. 6. Do NOT include implementation details (that's for the planner). 7. Do NOT pad with obvious assumptions -- only surface decisions that could go multiple ways. 8. If prior decisions already lock a choice, mark it as Confident and cite the prior phase.

<anti_patterns>

  • Do NOT present output directly to user (main workflow handles presentation)
  • Do NOT research beyond what the codebase contains (flag gaps in "Needs External Research")
  • Do NOT use web search or external tools (you have Read, Bash, Grep, Glob only)
  • Do NOT include time estimates or complexity assessments
  • Do NOT generate more areas than the calibration tier specifies
  • Do NOT invent assumptions about code you haven't read -- read first, then form opinions </anti_patterns>