@tgoodington/intuition 8.1.3 → 9.2.1

package/docs/v9/test/phase5b/stage1-many-decisions.md

@@ -0,0 +1,139 @@
+# Stage 1 Exploration: Task 5 — Build the API Integration Testing Skill
+
+## Research Findings
+
+Research subagents examined the following project context:
+
+- `src/api/routes/` — 14 route files covering auth, users, projects, billing, notifications, search, admin
+- `src/api/middleware/` — 6 middleware files (auth, rate-limit, cors, logging, validation, error-handler)
+- `tests/api/` — 23 existing test files, mostly unit tests on individual route handlers
+- `config/test.env` — test environment configuration with mock service URLs
+- `docs/api-spec.yaml` — OpenAPI 3.0 specification covering 42 endpoints
+
+Key findings:
+1. Existing tests are unit-level — no integration tests that exercise the full middleware stack
+2. OpenAPI spec is comprehensive but some endpoints are undocumented (admin routes)
+3. Auth middleware uses JWT with refresh tokens — integration tests need token management
+4. Rate limiting is per-IP in production, needs different handling in tests
+5. 3 external service dependencies: payment processor, email service, search index
+6. No test database seeding — tests currently use mocked data stores
+
+## ECD Analysis
+
+### Elements
+- **Endpoints**: 42 documented + ~6 undocumented admin endpoints
+- **Middleware stack**: 6 layers that transform requests/responses
+- **External services**: 3 dependencies requiring mocks or stubs
+- **Test database**: Needs seeding strategy for integration tests
+- **Auth flows**: JWT issue, refresh, revoke — all need test coverage
+- **OpenAPI spec**: Source of truth for expected request/response shapes
+
+### Connections
+- Routes → Middleware: each route passes through the full stack
+- Auth middleware → All protected routes: token validation required
+- External services → Route handlers: payment, email, search called from handlers
+- OpenAPI spec → Test assertions: response shapes validate against spec
+- Test DB → Route handlers: data layer needs realistic seeded state
+
+### Dynamics
+- Test setup: seed database, start mock services, configure auth tokens
+- Test execution: HTTP requests through the full stack (not bypassing middleware)
+- Assertion: response status, body shape (vs OpenAPI), headers, side effects
+- Teardown: clean database, verify no leaked state between tests
+- Edge cases: expired tokens, rate limit triggers, service timeouts, malformed requests
+
+## Assumptions
+
+### A1: Test Framework
+- **Default**: Use Jest with supertest (already in devDependencies)
+- **Rationale**: Project already uses Jest for unit tests; supertest is the standard HTTP assertion library for Node.js integration testing
+
+### A2: Single-File Skill Structure
+- **Default**: Implement as a single SKILL.md file
+- **Rationale**: Platform constraint — Claude Code skills must be single SKILL.md files
+
+### A3: Model Selection
+- **Default**: Use `sonnet` as the execution model
+- **Rationale**: Test generation is pattern-heavy, doesn't require opus-level reasoning
+
+## Key Decisions
+
+### D1: Test Scope — Which Endpoints
+- **Options**:
+  - A) All 42 documented endpoints — recommended
+  - B) Critical paths only (auth, billing, core CRUD) — ~15 endpoints
+  - C) All 48 including undocumented admin routes
+- **Recommendation**: A, because the OpenAPI spec provides a clear boundary and admin routes lack documentation to test against
+- **Risk if wrong**: All 42 is a large test suite; critical-only misses coverage; including admin routes means inventing expected behavior
+
+### D2: External Service Mocking Strategy
+- **Options**:
+  - A) In-process mocks (nock/msw) — intercept HTTP calls — recommended
+  - B) Sidecar mock servers — separate processes that mimic services
+  - C) Real staging services — use actual test instances
+- **Recommendation**: A, because in-process mocks are fastest, most deterministic, and don't require infrastructure
+- **Risk if wrong**: In-process mocks can mask real HTTP issues; sidecar is more realistic but harder to set up
+
+### D3: Database Strategy
+- **Options**:
+  - A) SQLite in-memory for tests — fast, isolated — recommended
+  - B) Dockerized test database (matching production)
+  - C) Shared test database with transaction rollback
+- **Recommendation**: A, because speed and isolation matter most for integration tests that run frequently
+- **Risk if wrong**: SQLite may have dialect differences from production DB; Docker is slower but more faithful
+
+### D4: Auth Token Management
+- **Options**:
+  - A) Pre-generated static tokens with known payloads — recommended
+  - B) Full auth flow per test (login → get token → use token)
+  - C) Bypass auth middleware in test environment
+- **Recommendation**: A, because static tokens are fastest and most deterministic for non-auth tests
+- **Risk if wrong**: Static tokens don't test the auth flow itself; bypassing auth misses middleware bugs
+
+### D5: Test Organization
+- **Options**:
+  - A) One test file per route file (14 files) — recommended
+  - B) One test file per endpoint (42 files)
+  - C) Grouped by domain (auth, billing, etc.) — ~6 files
+- **Recommendation**: A, because it mirrors the source structure and keeps related endpoint tests together
+- **Risk if wrong**: Large route files produce large test files; per-endpoint is more granular but creates file sprawl
+
+### D6: Response Validation Depth
+- **Options**:
+  - A) Schema validation against OpenAPI spec + key field assertions — recommended
+  - B) Full response body deep-equal matching
+  - C) Status code + content-type only
+- **Recommendation**: A, because schema validation catches structural issues while key field assertions verify business logic
+- **Risk if wrong**: Deep-equal is brittle (breaks on any field addition); status-only misses body bugs
+
+### D7: Error Case Coverage
+- **Options**:
+  - A) All documented error codes per endpoint — recommended
+  - B) Common errors only (400, 401, 404, 500)
+  - C) Happy path only, errors in a follow-up task
+- **Recommendation**: A, because error handling is where most integration bugs hide
+- **Risk if wrong**: Full error coverage is time-intensive; common-only misses domain-specific error cases
+
+### D8: Rate Limiting Test Approach
+- **Options**:
+  - A) Configurable rate limits — lower limits in test env for fast triggering — recommended
+  - B) Real rate limits — send enough requests to trigger
+  - C) Skip rate limit testing
+- **Recommendation**: A, because real limits make tests slow and flaky; skipping misses a critical middleware
+- **Risk if wrong**: Configurable limits might not catch production-specific rate limit bugs
+
+### D9: Test Data Seeding Strategy
+- **Options**:
+  - A) Fixture files loaded per test suite — recommended
+  - B) Factory functions that generate random data
+  - C) Shared seed script that populates a standard dataset
+- **Recommendation**: A, because fixtures are deterministic and reviewable; per-suite gives isolation
+- **Risk if wrong**: Fixtures can become stale; factories add complexity; shared seeds create test interdependencies
+
+### D10: CI Integration
+- **Options**:
+  - A) Separate CI job for integration tests (run on PR, not on every commit) — recommended
+  - B) Combined with unit tests in the same job
+  - C) Manual trigger only
+- **Recommendation**: A, because integration tests are slower and shouldn't block every commit
+- **Risk if wrong**: Separate job means integration failures discovered later; combined job slows all commits

package/docs/v9/test/phase5b/stage1-no-assumptions.md

@@ -0,0 +1,70 @@
+# Stage 1 Exploration: Task 4 — Build the Dependency Audit Skill
+
+## Research Findings
+
+Research subagents examined the following project context:
+
+- `package.json` — 12 dependencies, 8 devDependencies
+- `package-lock.json` — full dependency tree with 340 transitive dependencies
+- `config/audit-policy.json` — does not exist (no current audit configuration)
+- `reports/` — no existing audit reports
+
+Key findings:
+1. No existing audit tooling in the project
+2. `npm audit` available as baseline but produces verbose, hard-to-read output
+3. Several dependencies are 2+ major versions behind
+4. No license compliance checking currently
+
+## ECD Analysis
+
+### Elements
+- **Direct dependencies**: 20 packages declared in package.json
+- **Transitive dependencies**: 340 packages in the full tree
+- **Vulnerability database**: npm advisory database (via `npm audit`)
+- **License types**: Mix of MIT, Apache-2.0, ISC across the tree
+- **Audit report**: Markdown summary of findings
+
+### Connections
+- Direct deps → Transitive deps: each direct dep pulls in a subtree
+- Vulnerability DB → Dep versions: advisories match specific version ranges
+- License types → Compliance policy: some licenses may conflict with project goals
+- Audit report → User action: findings need clear next-step recommendations
+
+### Dynamics
+- Skill runs `npm audit --json` to get vulnerability data
+- Parses output into severity categories (critical, high, moderate, low)
+- Checks each dependency's license against an allow-list
+- Produces a ranked report: critical issues first, then version staleness, then license concerns
+- Edge case: private registry packages may not have advisory data
+
+## Key Decisions
+
+### D1: Scope of Audit
+- **Options**:
+  - A) Vulnerabilities only — focus on security advisories — recommended
+  - B) Vulnerabilities + license compliance
+  - C) Vulnerabilities + license compliance + version staleness
+- **Recommendation**: A, because it's the highest-value check and keeps the skill focused
+- **Risk if wrong**: Missing license issues could cause compliance problems; missing staleness info means outdated deps go unnoticed
+
+### D2: Transitive Dependency Depth
+- **Options**:
+  - A) Full tree — audit all 340 transitive dependencies — recommended
+  - B) Direct only — audit only the 20 declared dependencies
+- **Recommendation**: A, because vulnerabilities in transitive deps are the most common attack vector
+- **Risk if wrong**: Full tree is slower and noisier; direct-only misses the majority of real vulnerabilities
+
+### D3: Output Verbosity
+- **Options**:
+  - A) Summary with expandable details — top-level counts + per-issue breakdown — recommended
+  - B) Full verbose — every advisory for every package
+  - C) Executive summary only — just counts by severity
+- **Recommendation**: A, because it balances actionability with readability
+- **Risk if wrong**: Too verbose and users skip it; too brief and users can't act on it
+
+### D4: Remediation Suggestions
+- **Options**:
+  - A) Include fix commands — `npm update package@version` for each issue — recommended
+  - B) Flag issues only — user figures out the fix
+- **Recommendation**: A, because actionable output is more valuable than just flagging
+- **Risk if wrong**: Suggested commands might not account for breaking changes in major version bumps

package/docs/v9/test/phase5b/stage1-with-assumptions.md

@@ -0,0 +1,86 @@
+# Stage 1 Exploration: Task 3 — Build the Model Recommendation Engine
+
+## Research Findings
+
+Research subagents examined the following project context:
+
+- `models/catalog.json` — 47 model entries with fields: `ollama_id`, `name`, `parameter_count`, `quantization`, `context_length`, `ram_requirement_gb`, `gpu_vram_gb`
+- `config/hardware-profile.json` — user hardware: `ram_gb: 32`, `gpu_model: "RTX 4070"`, `gpu_vram_gb: 12`, `storage_available_gb: 200`
+- `reports/model_eval_2026-02-15_llama3.md` — existing evaluation report showing current output format
+- `skills/model-recommender/SKILL.md` — does not exist yet (greenfield task)
+
+Key findings:
+1. The catalog uses `ram_requirement_gb` (not `ram_gb`) as the field name for model RAM needs
+2. Context length varies from 2048 to 128000 — significant factor for recommendation
+3. Hardware profile has no CPU field — CPU-based inference not trackable
+4. Existing evaluation reports use a 3-tier rating: "excellent_fit", "acceptable_fit", "poor_fit"
+5. No existing recommendation logic — all current evaluations are manual
+
+## ECD Analysis
+
+### Elements
+- **Model entries**: 47 models with varying resource requirements
+- **Hardware profile**: Single JSON describing user's machine capabilities
+- **Recommendation output**: Markdown report ranking models by fit
+- **Fit score**: Composite metric weighing RAM, VRAM, and context requirements
+- **Use-case tags**: Models tagged with capabilities (chat, code, creative, reasoning)
+
+### Connections
+- Model requirements → Hardware profile: comparison determines feasibility
+- Use-case tags → User intent: filters the candidate list before scoring
+- Fit score → Ranking: determines output order
+- Existing report format → New output: should maintain consistency
+
+### Dynamics
+- User provides a use-case query ("I need a coding model")
+- Skill filters catalog by use-case tags
+- Remaining models scored against hardware profile
+- Top N models presented with fit explanations
+- Edge case: no models match the use-case → fallback to general recommendations
+
+## Assumptions
+
+### A1: Output Format Consistency
+- **Default**: Use the existing 3-tier rating system ("excellent_fit", "acceptable_fit", "poor_fit") from current evaluation reports
+- **Rationale**: Established convention in the project, no reason to introduce a new scale
+
+### A2: Single-File Skill Structure
+- **Default**: Implement as a single SKILL.md file
+- **Rationale**: Platform constraint — Claude Code skills must be single SKILL.md files with all instructions inline
+
+### A3: Model Selection for Execution
+- **Default**: Use `sonnet` as the execution model
+- **Rationale**: Standard model for task-type skills; recommendation logic doesn't require opus-level reasoning
+
+### A4: Hardware Profile Path
+- **Default**: Read hardware profile from `config/hardware-profile.json`
+- **Rationale**: Only hardware profile in the project, no alternative location
+
+### A5: Report Naming Convention
+- **Default**: `model_rec_YYYY-MM-DD_[use-case-slug].md`
+- **Rationale**: Matches the existing `model_eval_YYYY-MM-DD_[slug].md` pattern with appropriate prefix change
+
+## Key Decisions
+
+### D1: Scoring Formula Approach
+- **Options**:
+  - A) Weighted percentage — RAM fit (40%), VRAM fit (40%), context fit (20%) — recommended
+  - B) Binary pass/fail per dimension, then rank by headroom
+  - C) Single composite ratio (available/required) averaged across dimensions
+- **Recommendation**: A, because weighted percentage lets us tune importance per dimension and produces a continuous score for ranking
+- **Risk if wrong**: Wrong weights could rank a model with plenty of RAM but insufficient VRAM above a model that actually runs well
+
+### D2: Use-Case Filtering Strategy
+- **Options**:
+  - A) Strict tag match — only show models tagged with the requested use-case — recommended
+  - B) Fuzzy match — show tagged models first, then "might also work" models without the tag
+- **Recommendation**: A, because fuzzy matching risks confusing recommendations and the catalog tags are comprehensive
+- **Risk if wrong**: Strict filtering might miss capable models that lack tags (catalog completeness issue)
+
+### D3: Top-N Presentation Count
+- **Options**:
+  - A) Top 5 models — recommended
+  - B) Top 3 models
+  - C) All models that score above "acceptable_fit" threshold
+- **Recommendation**: A, because 5 gives enough variety without overwhelming, and the user can always ignore lower-ranked results
+- **Risk if wrong**: Too many results dilute the recommendation quality; too few might miss a good option

package/docs/v9/test/phase5b/test-5B-1-results.md

@@ -0,0 +1,157 @@
+# Test 5B-1: Assumptions/Decisions Split Format Compliance
+
+**Date:** 2026-02-27
+**Verdict:** PASS
+**Specialist Profile:** `code-architect.specialist.md` (phase5b updated version)
+**Task:** Task 2 — Build the Hardware Vetter Claude Code Skill
+**Output File:** `phase5b/scratch/code-architect-stage1.md`
+
+---
+
+## Criterion-by-Criterion Evaluation
+
+### 1. `## Assumptions` section exists with `### A1:`, `### A2:` entries
+
+**PASS**
+
+The output contains `## Assumptions` at the correct heading level (H2) with 7 entries numbered `### A1:` through `### A7:`, each at H3 level. Numbering is sequential and consistent.
+
+### 2. `## Key Decisions` section exists with `### D1:`, `### D2:` entries
+
+**PASS**
+
+The output contains `## Key Decisions` at H2 level with 3 entries numbered `### D1:` through `### D3:`, each at H3 level. Numbering is sequential and consistent.
+
+### 3. Each assumption has `**Default**:` and `**Rationale**:` fields
+
+**PASS**
+
+All 7 assumptions (A1-A7) contain both `**Default**:` and `**Rationale**:` fields with substantive content. Verified each:
+
+| Entry | **Default** present | **Rationale** present |
+|-------|--------------------|-----------------------|
+| A1 | Yes | Yes |
+| A2 | Yes | Yes |
+| A3 | Yes | Yes |
+| A4 | Yes | Yes |
+| A5 | Yes | Yes |
+| A6 | Yes | Yes |
+| A7 | Yes | Yes |
+
+### 4. Each decision has `**Options**:`, `**Recommendation**:`, `**Risk if wrong**:` fields
+
+**PASS**
+
+All 3 decisions (D1-D3) contain all three required fields with substantive content. Verified each:
+
+| Entry | **Options** present | **Recommendation** present | **Risk if wrong** present |
+|-------|--------------------|-----------------------------|---------------------------|
+| D1 | Yes (3 options) | Yes | Yes |
+| D2 | Yes (2 options) | Yes | Yes |
+| D3 | Yes (2 options) | Yes | Yes |
+
+Options follow the specified format with lettered sub-items (A, B, C) and the recommended option marked.
+
+### 5. Classification is reasonable (clear best practices as assumptions, genuine choices as decisions)
+
+**PASS**
+
+**Assumptions — all are clear best practices or obvious defaults:**
+- A1 (single-file structure): Mandated by platform constraint (Reference File Problem). No alternative.
+- A2 (fix `total_ram_gb`): Objectively wrong field name. Only one correct answer.
+- A3 (fix `gpu_vram_gb_fp16`): Nonexistent field. Only one correct answer.
+- A4 (preserve report format): Existing precedent, no reason to change.
+- A5 (match via `ollama_id`): Already working correctly. No alternative needed.
+- A6 (keep sonnet model): Standard model selection for the task type.
+- A7 (lightweight validation): Platform constraint makes deep validation infeasible.
+
+**Decisions — all have genuinely multiple valid approaches:**
+- D1 (scope: fix only vs enhancement): Real trade-off between minimal changes and adding features. Three distinct options with different risk/scope profiles.
+- D2 (remove/keep Glob tool): Minor but genuine choice with a non-obvious "keep and add use case" alternative.
+- D3 (patch vs rewrite): Classic engineering trade-off with real arguments on both sides.
+
+### 6. No items that obviously belong in the other category
+
+**PASS**
+
+No classification errors found. Reviewed each item:
+
+- No assumption has multiple valid approaches that warrant user input. Each has a single obvious default.
+- No decision is a clear best practice that should be assumed. Each involves a genuine trade-off.
+- D2 (Glob tool) is borderline — it is low-stakes enough to be an assumption — but it does have two distinct approaches, so classification as a decision is defensible. Not flagged as an error.
+
+### 7. Format compliance: exact heading levels and field labels as specified
+
+**PASS**
+
+Verified against Section 9.8.1 specification:
+
+| Element | Spec | Output | Match |
+|---------|------|--------|-------|
+| Top heading | `# Stage 1 Exploration: [Task Title]` | `# Stage 1 Exploration: Task 2 — Build the Hardware Vetter Claude Code Skill` | Yes |
+| Research section | `## Research Findings` | `## Research Findings` | Yes |
+| ECD section | `## ECD Analysis` | `## ECD Analysis` | Yes |
+| ECD subsections | `### Elements`, `### Connections`, `### Dynamics` | All three present at H3 | Yes |
+| Assumptions section | `## Assumptions` | `## Assumptions` | Yes |
+| Assumption entries | `### A1: [Title]` | `### A1: Single-File Skill Structure` etc. | Yes |
+| Assumption fields | `**Default**:`, `**Rationale**:` | Present in all entries | Yes |
+| Decisions section | `## Key Decisions` | `## Key Decisions` | Yes |
+| Decision entries | `### D1: [Title]` | `### D1: Scope of Changes — Fix Only vs Enhancement` etc. | Yes |
+| Decision fields | `**Options**:`, `**Recommendation**:`, `**Risk if wrong**:` | Present in all entries | Yes |
+| Options sub-format | Lettered `A)`, `B)`, `C)` with recommended marked | Yes, with "— recommended" tag | Yes |
+| Risks section | `## Risks Identified` | `## Risks Identified` | Yes |
+| Approach section | `## Recommended Approach` | `## Recommended Approach` | Yes |
+
+Section order matches spec: Research Findings → ECD Analysis → Assumptions → Key Decisions → Risks Identified → Recommended Approach.
+
+---
+
+## Items Produced and Their Classifications
+
+### Assumptions (7 items)
+
+| ID | Title | Default | Classification Correctness |
+|----|-------|---------|---------------------------|
+| A1 | Single-File Skill Structure | Keep as single SKILL.md | Correct — platform constraint, no alternative |
+| A2 | Fix `total_ram_gb` Field Name Mismatch | Change to `ram_gb` | Correct — objectively wrong, single fix |
+| A3 | Fix `gpu_vram_gb_fp16` Reference | Remove/correct the dead reference | Correct — nonexistent field, must fix |
+| A4 | Preserve Existing Report Format | Keep `hardware_eval_YYYY-MM-DD_[slug].md` | Correct — established convention |
+| A5 | Match via `ollama_id` Field | Continue using `ollama_id` for matching | Correct — already working, no alternative |
+| A6 | Keep `sonnet` as Execution Model | Retain `model: sonnet` | Correct — standard model for task type |
+| A7 | Lightweight Schema Validation | Existence checks only, no deep validation | Correct — platform constraint |
+
+### Key Decisions (3 items)
+
+| ID | Title | Options Count | Classification Correctness |
+|----|-------|---------------|---------------------------|
+| D1 | Scope of Changes — Fix Only vs Enhancement | 3 (fix only / +unified memory / +concurrent loading) | Correct — genuine scope trade-off |
+| D2 | Remove or Keep Unused `Glob` Tool | 2 (remove / keep+add use case) | Correct (borderline — low stakes, but two valid approaches) |
+| D3 | Review-and-Patch vs Rewrite | 2 (patch / rewrite) | Correct — classic engineering trade-off |
+
+---
+
+## Classification Errors
+
+**None found.**
+
+D2 is the weakest classification — removing an unused tool is close to a best practice. However, the "keep and add a use case" option is a genuinely different approach (adding functionality rather than removing surface area), so the decision classification is defensible.
+
+---
+
+## Format Compliance Issues
+
+**None found.**
+
+All heading levels, field labels, section ordering, and entry numbering match the Section 9.8.1 specification exactly. The output would be parseable by a foreground skill scanning for `## Assumptions`, `### A\d+:`, `## Key Decisions`, `### D\d+:` patterns.
+
+---
+
+## Recommendations for Specialist Profile
+
+1. **No critical changes needed.** The updated profile's Stage 1 protocol successfully guided production of correctly formatted output with reasonable classifications.
+
+2. **Consider adding a guideline for borderline items.** D2 (Glob tool) is borderline between assumption and decision. The current "if uncertain, classify as decision" rule handled this correctly, but an additional heuristic could help: "If the item has low risk regardless of choice AND one option is clearly simpler, classify as assumption."
+
+3. **Consider adding a count guideline.** The spec does not say how many assumptions vs decisions to expect. For this task, 7 assumptions and 3 decisions is a reasonable split, but for tasks with more unknowns, the ratio could flip. A note like "Most well-researched tasks will have more assumptions than decisions; if you have more decisions than assumptions, verify you're not over-asking" could improve calibration.
+
+4. **Options format worked well.** The "— recommended" tag inline with the option text is clearer than having it only in the Recommendation field. Consider making this a documented convention in the spec.

package/docs/v9/test/phase5b/test-5B-10-results.md

@@ -0,0 +1,130 @@
+# Test 5B-10: Stage 2 Honoring decisions.json
+
+**Date:** 2026-02-28
+**Verdict:** PASS
+
+---
+
+## Objective
+
+Validate that a Stage 2 subagent correctly consumes decisions.json and produces a blueprint that honors all user overrides, promotions, and custom "Other" inputs.
+
+## Input
+
+- **stage1.md**: `stage1-with-assumptions.md` (5 assumptions + 3 decisions)
+- **decisions.json**: `decisions/5B-3-promote-decisions.json` — the richest test case:
+  - A3 promoted: sonnet → opus
+  - A5 promoted: date-based naming → `recommendation_[use-case-slug].md`
+  - D1: recommended option (A — weighted percentage)
+  - D2: "Other" with custom text ("strict tag match but also include models tagged as 'general'")
+  - D3: non-recommended option (C — all above threshold, not top-5)
+
+## Compliance Check
+
+### Promoted Assumption A3: Model Selection → opus
+
+| Location | Expected | Found | Match |
+|----------|----------|-------|-------|
+| Section 4 Decisions table | `opus` noted as promoted override | "**Use `opus`** (not sonnet) — **Promoted**" | Yes |
+| Section 5.2 YAML frontmatter | `model: opus` | `model: opus` | Yes |
+| Section 9 Producer Handoff | `opus` | "Execution Model: `opus` (per A3 user override)" | Yes |
+
+**PASS** — opus appears in all three locations where model selection matters. The default "sonnet" does not appear as the selected model anywhere in the blueprint.
+
+### Promoted Assumption A5: Naming Convention → `recommendation_[use-case-slug].md`
+
+| Location | Expected | Found | Match |
+|----------|----------|-------|-------|
+| Section 4 Decisions table | Override naming noted | "**Use `recommendation_[use-case-slug].md`** (no date prefix) — **Promoted**" | Yes |
+| Section 5.4 Output data contract | `recommendation_[use-case-slug].md` | "reports/recommendation_[use-case-slug].md" | Yes |
+| Section 5.8 Report generation | Uses override naming | Report written to `reports/recommendation_[slug].md` | Yes |
+| Section 1 Acceptance Criteria AC6 | Override naming | "`recommendation_[use-case-slug].md` convention" | Yes |
+
+**PASS** — The date-based `model_rec_YYYY-MM-DD_[slug].md` pattern does not appear anywhere. Override naming used consistently.
+
+### Decision D1: Scoring Formula → Weighted Percentage (Option A)
+
+| Location | Expected | Found | Match |
+|----------|----------|-------|-------|
+| Section 3 Approach | Weighted percentage referenced | "RAM fit 40%, VRAM fit 40%, context fit 20% (per D1)" | Yes |
+| Section 5.6 Scoring Formula | Full formula with 40/40/20 weights | Complete formula with `ram_ratio * 0.40 + vram_ratio * 0.40 + context_ratio * 0.20` | Yes |
+| Section 6 Acceptance Mapping AC2 | Formula referenced | "Complete formula with per-dimension calculation, capping, and edge cases" | Yes |
+
+**PASS** — Scoring formula exactly matches the user's choice. Weights are 40/40/20 as specified.
+
+### Decision D2: Filtering → "Other" (strict match + general tag inclusion)
+
+| Location | Expected | Found | Match |
+|----------|----------|-------|-------|
+| Section 3 Approach | Custom filtering referenced | "always including models tagged 'general' regardless of query (per D2 user override)" | Yes |
+| Section 5.5 Filtering Logic | Pseudocode implements both paths | Strict tag match PLUS `else if model.use_case_tags contains "general"` | Yes |
+| Section 8 Open Items | "general" tag existence flagged | "D2 user override assumes models have a 'general' tag. Stage 1 did not confirm 'general' exists" | Yes |
+
+**PASS** — The user's custom "Other" input was correctly interpreted and implemented. Both the strict match AND the general-tag inclusion appear in the filtering pseudocode. Critically, the blueprint also flagged an open item: Stage 1 never confirmed "general" exists as an actual tag in the catalog. This is exactly the kind of research gap that Stage 2 should surface.
+
+### Decision D3: Presentation → All Above Threshold (Option C)
+
+| Location | Expected | Found | Match |
+|----------|----------|-------|-------|
+| Section 3 Approach | All above threshold referenced | "all models at or above 'acceptable_fit' (per D3)" | Yes |
+| Section 5.8 Report Generation | No top-N cap | "all models that score at or above the 'acceptable_fit' threshold (fit_score >= 0.55)" | Yes |
+| Section 1 AC4 | Option C language | "all models above the 'acceptable_fit' threshold" | Yes |
+
+**PASS** — No trace of "top 5" anywhere in the blueprint. The specialist's original recommendation (option A) was correctly overridden.
+
+### Accepted Assumptions (A1, A2, A4) — Defaults Preserved
+
+| Assumption | Default | Found in Blueprint | Match |
+|------------|---------|-------------------|-------|
+| A1: 3-tier rating | excellent_fit, acceptable_fit, poor_fit | Section 5.7 Tier Classification uses all three tiers | Yes |
+| A2: Single SKILL.md | Single file | Section 5.1 "single Markdown file", Section 5.10 structure | Yes |
+| A4: Hardware path | config/hardware-profile.json | Section 5.4 data contract | Yes |
+
+**PASS** — All three accepted defaults correctly used without modification.
+
+---
+
+## Research Grounding Evaluation
+
+Checked against the D23 grounding rule: every design choice traceable to (a) Stage 1 research, (b) user decision, or (c) named domain standard.
+
+| Design Choice | Grounded To | Grounding Quality |
+|---------------|-------------|-------------------|
+| RAM field name `ram_requirement_gb` | Stage 1 finding #1 | Correct — used the exact field name from research |
+| Scoring formula weights | D1 (user confirmed option A) | Correct |
+| Filtering logic with "general" tag | D2 (user "Other" input) | Correct |
+| All-above-threshold presentation | D3 (user chose option C) | Correct |
+| Tier thresholds 0.85/0.55 | NOT in Stage 1 or decisions | **Correctly flagged as Open Item** |
+| "general" tag existence | NOT confirmed by Stage 1 | **Correctly flagged as Open Item** |
+| `use_case_tags` field name | NOT confirmed by Stage 1 | **Correctly flagged as Open Item** |
+
+**PASS** — All three ungrounded design choices were properly surfaced in Open Items. Stage 2 did not silently invent thresholds or assume field names without flagging them.
+
+---
+
+## Summary
+
+Stage 2 correctly honored all 8 items from decisions.json:
+- 2 promoted assumptions with overrides → both reflected throughout the blueprint
+- 1 "Other" decision with custom text → interpreted and implemented correctly, with open item flagged
+- 1 non-recommended option → specialist's recommendation correctly overridden
+- 1 recommended option → confirmed and implemented
+- 3 accepted assumptions → defaults preserved without modification
+
+The research grounding rule worked as intended: 3 design choices not covered by Stage 1 or user decisions were surfaced in Open Items rather than silently invented.
+
+---
+
+## Protocol Validation
+
+This test closes the last gap in the Stage 1 → gate → Stage 2 pipeline validation:
+
+| Test | What it validated |
+|------|------------------|
+| S1 | Stage 1 produces quality research |
+| 5B-1 | Stage 1 produces correct assumptions/decisions format |
+| 5B-2 through 5B-9 | Gate protocol correctly parses, presents, collects, persists, recovers |
+| S2/S3 | Stage 2 produces a buildable blueprint |
+| **5B-10** | **Stage 2 correctly consumes decisions.json with overrides** |
+
+The complete pipeline is validated end-to-end at the protocol design level.

package/docs/v9/test/phase5b/test-5B-2-results.md

@@ -0,0 +1,75 @@
+# Test 5B-2: Gate Phase 1 — Accept All Assumptions
+
+**Date:** 2026-02-27
+**Verdict:** PASS
+
+---
+
+## Simulation Walkthrough
+
+**Input:** `stage1-with-assumptions.md` — 5 assumptions (A1-A5) + 3 decisions (D1-D3).
+
+### Step 1: Gate reads stage1.md, finds `## Assumptions` with 5 entries
+
+Gate extracts A1-A5 with titles and defaults.
+
+### Step 2: Phase 1 — Present assumptions as group
+
+Gate displays:
+
+```
+The specialist proposes these defaults:
+
+A1: Output Format Consistency — Use existing 3-tier rating system (established convention)
+A2: Single-File Skill Structure — Implement as a single SKILL.md file (platform constraint)
+A3: Model Selection for Execution — Use sonnet (standard for task-type skills)
+A4: Hardware Profile Path — Read from config/hardware-profile.json (only location)
+A5: Report Naming Convention — model_rec_YYYY-MM-DD_[use-case-slug].md (matches existing pattern)
+
+Accept all, or tell me which ones you want to weigh in on.
+```
+
+AskUserQuestion options:
+- "Accept all assumptions (Recommended)"
+- "I want to review some of these"
+
+### Step 3: User selects "Accept all assumptions"
+
+All 5 assumptions written to decisions.json with `"status": "accepted"`, `"user_override": null`.
+
+### Step 4: Gate moves to Phase 2
+
+Presents D1, D2, D3 individually via AskUserQuestion.
+
+Simulated responses:
+- D1: Accepts recommended (A — Weighted percentage)
+- D2: Picks non-recommended (B — Fuzzy match)
+- D3: Accepts recommended (A — Top 5)
+
+### Step 5: decisions.json complete
+
+See `decisions/5B-2-accept-all-decisions.json`.
+
+---
+
+## Criterion-by-Criterion Evaluation
+
+### 1. decisions.json has all 5 assumptions with `"status": "accepted"`, `"user_override": null`
+
+**PASS** — All 5 assumptions present with correct status and null override.
+
+### 2. Gate moves directly to Phase 2 decisions
+
+**PASS** — After "Accept all", no individual assumption questions. Gate proceeds to D1 immediately.
+
+### 3. No assumptions are presented as decisions
+
+**PASS** — A1-A5 appear only in the `assumptions` array. D1-D3 appear only in the `decisions` array. No cross-contamination.
+
+---
+
+## Protocol Validation Notes
+
+1. The "accept all" fast path works as designed — one click resolves all 5 assumptions.
+2. The group presentation format is compact enough to scan quickly. One-line rationale in parentheses is sufficient context.
+3. Phase 2 proceeds with exactly 3 decisions — no assumptions leaked into the decision flow.