@zigrivers/scaffold 3.1.0 → 3.4.1

package/content/knowledge/core/test-skeleton-generation.md

@@ -0,0 +1,313 @@
+---
+name: test-skeleton-generation
+description: Patterns for translating acceptance criteria into framework-specific test skeleton files
+topics: [testing, test-generation, acceptance-criteria, tdd, test-skeletons]
+---
+
+# Test Skeleton Generation
+
+This knowledge covers the translation of user story acceptance criteria (Given/When/Then format) into framework-specific test skeleton files. Skeletons are pending/skipped test stubs — they document expected behavior and provide a TDD starting point, but contain no implementation logic.
+
+This is distinct from testing strategy (`testing-strategy`), which covers overall test architecture, and user stories (`user-stories`), which covers story authoring. This knowledge bridges the two: given well-written ACs and a chosen test framework, produce a complete set of traceable test skeletons.
+
+## Summary
+
+- **Purpose**: Translate user story acceptance criteria (Given/When/Then) into pending test cases in the project's test framework, one test per AC.
+- **Output format**: One test file per story (or per epic), with each AC as a pending/skipped test case that documents the expected behavior without implementing it.
+- **Framework mapping**: `describe` = story, `it`/`test` = AC criterion. For frameworks without pending support, use `it.skip` or `@pytest.mark.skip` with the AC text as the test name.
+- **Layer assignment**: Each test skeleton is tagged with its execution layer (unit, integration, e2e) based on what the AC tests — data validation = unit, API flow = integration, user workflow = e2e.
+- **ID tracing**: Every test name includes the story ID and criterion ID (e.g., `US-3.2: Given a logged-in user...`) so implementation agents can trace tests back to requirements.
+- **Story-tests-map**: A traceability matrix (`docs/story-tests-map.md`) maps every story to its test files, every AC to its test case, and assigns execution layers.
+
+## Deep Guidance
+
+### Scope Boundary
+
+**In scope:**
+- Translating GWT acceptance criteria into pending test stubs
+- Assigning test execution layers (unit, integration, e2e)
+- Creating the story-tests-map traceability matrix
+- Framework-specific skeleton patterns (vitest, pytest, bats, Go, etc.)
+- Test file naming and directory conventions
+
+**Out of scope:**
+- Implementing test logic (skeletons are stubs only)
+- Choosing the test framework (read `docs/tech-stack.md`)
+- Writing acceptance criteria (that's the user stories step)
+- Test infrastructure setup (that's the TDD standards step)
+
+---
+
+### Translation Rules
+
+**Given/When/Then to Test Structure:**
+
+The GWT format maps directly to the Arrange/Act/Assert pattern used in every test framework:
+
+```
+Given [precondition]     ->  test setup / arrange
+When [action]            ->  act / trigger
+Then [expected outcome]  ->  assert / verify
+And [additional outcome] ->  additional assertion
+```
+
+Multiple `Given` clauses become multiple setup steps. Multiple `Then` clauses become multiple assertions in the same test. `And` following a `Given` is another precondition; `And` following a `Then` is another assertion.
+
+**Compound ACs:**
+
+When an AC has multiple `When` clauses, each `When` is a separate test case. The common `Given` preconditions are shared setup (a `beforeEach` or fixture), and each `When/Then` pair becomes its own test.
+
+---
+
+### Framework-Specific Patterns
+
+#### vitest / jest (TypeScript/JavaScript)
+
+```typescript
+import { describe, it } from 'vitest';
+
+describe('US-3: User can reset their password', () => {
+  it.skip('AC-3.1: Given a registered user, when they request a password reset, then a reset email is sent', () => {
+    // Arrange: registered user exists
+    // Act: request password reset
+    // Assert: reset email sent
+  });
+
+  it.skip('AC-3.2: Given a valid reset token, when the user submits a new password, then the password is updated', () => {
+    // Arrange: valid reset token exists
+    // Act: submit new password
+    // Assert: password updated in database
+  });
+
+  it.skip('AC-3.3: Given an expired reset token, when the user submits a new password, then an error is shown', () => {
+    // Arrange: expired reset token
+    // Act: submit new password
+    // Assert: error message displayed, password unchanged
+  });
+});
+```
+
+#### pytest (Python)
+
+```python
+import pytest
+
+class TestUS3UserCanResetPassword:
+    """US-3: User can reset their password"""
+
+    @pytest.mark.skip(reason="skeleton")
+    def test_ac_3_1_given_registered_user_when_request_reset_then_email_sent(self):
+        """AC-3.1: Given a registered user, when they request a password reset, then a reset email is sent"""
+        # Arrange: registered user exists
+        # Act: request password reset
+        # Assert: reset email sent
+        pass
+
+    @pytest.mark.skip(reason="skeleton")
+    def test_ac_3_2_given_valid_token_when_submit_password_then_updated(self):
+        """AC-3.2: Given a valid reset token, when the user submits a new password, then the password is updated"""
+        # Arrange: valid reset token exists
+        # Act: submit new password
+        # Assert: password updated in database
+        pass
+```
+
+#### bats (Bash)
+
+```bash
+# US-3: User can reset their password
+
+@test "AC-3.1: Given a registered user, when they request a password reset, then a reset email is sent" {
+  skip "skeleton"
+  # Arrange: registered user exists
+  # Act: request password reset
+  # Assert: reset email sent
+}
+
+@test "AC-3.2: Given a valid reset token, when the user submits a new password, then the password is updated" {
+  skip "skeleton"
+  # Arrange: valid reset token exists
+  # Act: submit new password
+  # Assert: password updated in database
+}
+```
+
+#### Go testing
+
+```go
+func TestUS3_UserCanResetPassword(t *testing.T) {
+    t.Run("AC-3.1: Given a registered user, when they request a password reset, then a reset email is sent", func(t *testing.T) {
+        t.Skip("skeleton")
+        // Arrange: registered user exists
+        // Act: request password reset
+        // Assert: reset email sent
+    })
+
+    t.Run("AC-3.2: Given a valid reset token, when the user submits a new password, then the password is updated", func(t *testing.T) {
+        t.Skip("skeleton")
+        // Arrange: valid reset token exists
+        // Act: submit new password
+        // Assert: password updated in database
+    })
+}
+```
+
+### Framework-Specific Summary Table
+
+| Framework | Story Group | Test Case | Pending Marker |
+|-----------|------------|-----------|----------------|
+| vitest/jest | `describe('US-3: Story title')` | `it('AC-3.1: Given X when Y then Z')` | `it.skip(...)` or `it.todo(...)` |
+| pytest | `class TestUS3StoryTitle:` | `def test_ac_3_1_given_x_when_y_then_z(self):` | `@pytest.mark.skip(reason='skeleton')` |
+| bats | comment block with story ID | `@test "AC-3.1: Given X when Y then Z"` | `skip "skeleton"` |
+| Go testing | `func TestUS3_StoryTitle(t *testing.T)` | `t.Run("AC-3.1: Given X when Y then Z", ...)` | `t.Skip("skeleton")` |
+| RSpec | `describe 'US-3: Story title'` | `it 'AC-3.1: ...'` | `xit 'AC-3.1: ...'` or `pending` |
+| JUnit 5 | `@Nested class US3_StoryTitle` | `@Test @Disabled("skeleton")` | `@Disabled("skeleton")` |
+
+---
+
+### Layer Assignment Heuristic
+
+Each test skeleton is tagged with its execution layer. This determines where the test runs in CI and what infrastructure it requires.
+
+| AC Pattern | Layer | Example |
+|------------|-------|---------|
+| Validates input/output of a single function | Unit | "Then the email format is validated" |
+| Tests interaction between components | Integration | "Then the order is saved to the database" |
+| Tests a user-visible workflow end-to-end | E2E | "Then the user sees a confirmation page" |
+| Tests error handling at a boundary | Integration | "Then a 400 error is returned with details" |
+| Tests a non-functional requirement | Varies | Perf = benchmark, security = integration |
+
+#### Layer Decision Rules
+
+When the layer is ambiguous, apply these rules in order:
+
+1. **Does the AC mention a UI element or user-visible state?** → E2E
+2. **Does the AC cross a service or component boundary?** → Integration
+3. **Does the AC test a single function's behavior with known inputs/outputs?** → Unit
+4. **Does the AC test data persistence or retrieval?** → Integration
+5. **Does the AC test an external service interaction?** → Integration (with mocks)
+
+#### Layer Tags in Test Files
+
+Add layer tags as comments or test metadata so CI can filter by layer:
+
+```typescript
+// @layer: integration
+describe('US-3: User can reset their password', () => { ... });
+```
+
+```python
+@pytest.mark.integration
+class TestUS3UserCanResetPassword:
+    ...
+```
+
+---
+
+### Test File Naming and Organization
+
+#### File Naming Convention
+
+Test files follow the pattern: `{story-id}-{slug}.test.{ext}`
+
+Examples:
+- `us-1-user-registration.test.ts`
+- `us-2-password-reset.test.ts`
+- `us-3-profile-management.test.ts`
+
+The story ID prefix ensures files sort in story order. The slug provides human-readable context.
+
+#### Directory Structure
+
+Test skeletons go in the acceptance test directory defined in `docs/project-structure.md`. If no convention exists, default to:
+
+```
+tests/
+  acceptance/
+    us-1-user-registration.test.ts
+    us-2-password-reset.test.ts
+    us-3-profile-management.test.ts
+```
+
+For projects that split tests by layer:
+
+```
+tests/
+  unit/
+    us-1-user-registration.unit.test.ts
+  integration/
+    us-1-user-registration.integration.test.ts
+  e2e/
+    us-1-user-registration.e2e.test.ts
+```
+
+---
+
+### Story-Tests-Map Format
+
+The `docs/story-tests-map.md` output maps every story to its test files. This is the primary traceability artifact.
+
+```markdown
+# Story-Tests Map
+
+## Coverage Summary
+
+| Metric | Value |
+|--------|-------|
+| Total stories | 12 |
+| Stories with tests | 12 |
+| Total ACs | 47 |
+| ACs with test cases | 47 |
+| Coverage | 100% |
+
+## Traceability Matrix
+
+| Story ID | Story Title | Test File | Layer | AC Count |
+|----------|------------|-----------|-------|----------|
+| US-1 | User registration | tests/acceptance/us-1-registration.test.ts | integration | 4 |
+| US-2 | Password reset | tests/acceptance/us-2-password-reset.test.ts | e2e | 3 |
+| US-3 | Profile management | tests/acceptance/us-3-profile.test.ts | unit | 5 |
+```
+
+The map must be updated whenever stories are added, removed, or have ACs changed. In update mode, new rows are appended and the coverage summary is recalculated.
+
+---
+
+### Handling Edge Cases
+
+#### Stories Without GWT Format
+
+If acceptance criteria are not in Given/When/Then format, convert them:
+- "Users can search by keyword" → "Given a user on the search page, when they enter a keyword and submit, then matching results are displayed"
+- Preserve the original AC text as a comment in the test case
+
+#### Stories With Many ACs
+
+Stories with more than 10 ACs may indicate the story is too large. Flag this in the story-tests-map but generate all skeletons regardless — the story decomposition is a separate concern.
+
+#### Shared Preconditions
+
+When multiple ACs share the same `Given` precondition, use the framework's shared setup:
+- vitest/jest: `beforeEach` or `beforeAll`
+- pytest: `@pytest.fixture`
+- bats: `setup()`
+- Go: helper function called at the start of each subtest
+
+#### Negative Test Cases
+
+For deep methodology, generate negative test cases for each happy-path AC:
+- "Given X, when Y, then Z" → also generate "Given NOT X, when Y, then error"
+- Negative cases get their own AC IDs: `AC-3.1-NEG`
+
+---
+
+### Anti-Patterns
+
+- Don't implement test logic — skeletons are pending/skipped stubs only
+- Don't combine multiple ACs into one test — one AC = one test case
+- Don't omit the story/criterion ID from test names — traceability is the point
+- Don't guess the test framework — read `docs/tech-stack.md` and `docs/tdd-standards.md`
+- Don't create test files outside the project's test directory convention
+- Don't add assertion logic to skeletons — that's the implementation agent's job
+- Don't generate skeletons for non-functional requirements unless they have explicit ACs
+- Don't skip the story-tests-map — it's the verification artifact that proves coverage

package/{knowledge → content/knowledge}/execution/enhancement-workflow.md

@@ -42,7 +42,7 @@ Read these documents in order before proposing any changes:
 1. **Product vision** (`docs/vision.md` or equivalent) — understand the project's purpose and direction
 2. **PRD** (`docs/prd.md`) — understand existing requirements and constraints
 3. **User stories** (`docs/user-stories.md`) — understand who uses the system and how
-4. **Architecture** (`docs/architecture.md` or ADRs) — understand the technical structure
+4. **Architecture** (`docs/system-architecture.md` or ADRs) — understand the technical structure
 5. **Coding standards** (`docs/coding-standards.md`) — understand conventions you must follow
 6. **TDD standards** (`docs/tdd-standards.md`) — understand testing expectations
 7. **Project structure** (`docs/project-structure.md`) — understand where code lives

package/content/knowledge/product/vision-innovation.md

@@ -0,0 +1,273 @@
+---
+name: vision-innovation
+description: Techniques for discovering strategic innovation opportunities in product vision
+topics: [innovation, vision, strategy, competitive-positioning, ecosystem, market-opportunities]
+---
+
+# Vision Innovation
+
+This knowledge covers strategic-level innovation — discovering market positioning opportunities, ecosystem plays, contrarian bets, and AI-native rethinking that belong in the product vision. It operates at the strategic scope level: how should this product be positioned in the market?
+
+This is distinct from PRD innovation (`prd-innovation`), which covers feature-level gaps, and user story innovation (`user-story-innovation`), which covers UX-level enhancements. If an idea is about a specific feature or UX improvement, it belongs in those respective knowledge entries, not here.
+
+## Summary
+
+- **Scope**: Strategic-level innovation (market positioning, ecosystem plays, contrarian bets, AI-native capabilities). Feature-level innovation belongs in PRD innovation (`prd-innovation`); UX-level improvements belong in user story innovation (`user-story-innovation`).
+- **Adjacent market discovery**: Look for underserved segments adjacent to the primary target — same problem in different industries, same users with upstream/downstream needs, or existing users with unmet complementary needs.
+- **Ecosystem thinking**: Identify integration points, platform plays, and data network effects — where does the product become more valuable as usage grows or connections multiply?
+- **Contrarian positioning**: Challenge assumptions the market takes for granted — what would a solution look like if you ignored the dominant UX pattern, pricing model, or distribution channel?
+- **AI-native opportunities**: Capabilities only possible with AI (real-time personalization, natural language interfaces, predictive workflows, automated quality feedback) that would be impractical to build conventionally.
+- **Evaluation framework**: Strategic fit x Defensibility x Timing. Must-have for vision = high strategic fit with defensibility, achievable in v1 timeline.
+
+## Deep Guidance
+
+### Scope Boundary
+
+**In scope:**
+- Market positioning and competitive strategy
+- Adjacent market and segment identification
+- Ecosystem and platform plays
+- Network effect opportunities
+- Contrarian bets and assumption challenges
+- AI-native strategic rethinking of the product concept
+- Business model innovation (pricing, distribution, partnerships)
+
+**Out of scope:**
+- Specific feature ideas (belongs in PRD innovation)
+- UX improvements to existing features (belongs in user story innovation)
+- Implementation details (belongs in ADRs and architecture docs)
+- Operational concerns (belongs in operations planning)
+
+---
+
+### Strategic Innovation Framework
+
+Apply these lenses sequentially. Each builds on the previous:
+
+**1. Market Landscape Scan**
+- Who are the 3-5 closest competitors? What do they all assume?
+- Which customer segments are poorly served by existing solutions?
+- What friction points exist in the current adoption/onboarding flow industry-wide?
+- Are there geographic, regulatory, or industry verticals where existing solutions don't work?
+- What recent market shifts (technology, regulation, cultural) create new openings?
+
+**2. Ecosystem & Platform Analysis**
+- What data does this product generate that others would find valuable?
+- What integrations would make this product "sticky" (hard to leave)?
+- Could this product become a platform that others build on?
+- What network effects are possible (direct: more users = more value; indirect: more content/data = better product)?
+- Where could partnerships create mutual value that neither party could achieve alone?
+
+**3. Contrarian & Blue Ocean Opportunities**
+- What would the product look like if it cost 10x less? 10x more?
+- What if the primary interface were voice? Chat? No interface at all?
+- What if the product solved the problem *before* the user knew they had it?
+- Which "table stakes" features could be dropped entirely for a specific segment?
+- What assumptions about the target user are untested?
+
+**4. AI-Native Capabilities**
+- Where can the product anticipate user intent rather than waiting for commands?
+- What manual steps could be eliminated with LLM-powered analysis?
+- Where can the product learn from usage patterns without explicit configuration?
+- What would a "copilot" experience look like for this domain?
+- Which competitive advantages become possible only with AI at the core?
+
+---
+
+### Adjacent Market Discovery
+
+Adjacent markets are the highest-value innovation targets because they leverage existing product capabilities for new audiences.
+
+#### Discovery Techniques
+
+**Same problem, different industry:**
+The product solves a problem for industry A. Which other industries have the same problem with slightly different constraints? Example: project management for software teams → project management for construction, legal, or healthcare teams.
+
+**Same users, upstream/downstream needs:**
+The product's target users have needs before and after they use the product. What happens before they arrive? What do they do with the output? Example: a reporting tool's users need data collection upstream and presentation downstream.
+
+**Existing users, unmet complementary needs:**
+What do current target users also struggle with that the product could address? Example: a CRM user also needs contract management, scheduling, and billing.
+
+#### Evaluation
+
+For each adjacent market:
+- Size: Is the adjacent market large enough to justify the positioning shift?
+- Overlap: How much of the existing product applies without modification?
+- Competition: Is the adjacent market underserved or already crowded?
+- Brand stretch: Can the product credibly serve both the original and adjacent markets?
+
+---
+
+### Ecosystem & Platform Thinking
+
+Products that become platforms or ecosystem hubs are harder to displace and grow more valuable over time.
+
+#### Integration Strategy
+
+Identify the top 5-10 tools in the target user's workflow. For each:
+- Does integrating with this tool make the product more valuable?
+- Does the integration create switching costs (data flows that are hard to replicate)?
+- Is the integration bidirectional (data flows both ways)?
+
+#### Data Network Effects
+
+The most defensible products generate data that makes the product better:
+- Usage data that improves recommendations or predictions
+- Aggregated data that provides benchmarks or insights
+- Content created by users that attracts other users
+- Training data that improves AI capabilities over time
+
+#### Platform Potential
+
+Could third parties build on this product? Signs of platform potential:
+- The product has a natural extension point (plugins, templates, integrations)
+- Users want to customize the product beyond what's built-in
+- The product generates data or output that others want to consume
+- There's a community of practitioners who would build for peers
+
+---
+
+### Contrarian Positioning
+
+The most differentiated products challenge at least one industry assumption. Contrarian positioning creates separation from competitors who all look the same.
+
+#### Assumption Mapping
+
+List the 5-10 things "everyone knows" about the product category:
+- The standard pricing model (subscription, per-seat, usage-based)
+- The standard distribution channel (direct sales, self-serve, marketplace)
+- The standard UX pattern (dashboard, wizard, chat, forms)
+- The standard feature set (what every competitor has)
+- The standard target user (who everyone is selling to)
+
+For each assumption, ask: "What if the opposite were true?" Most answers will be absurd. One or two will be genuinely interesting.
+
+#### Blue Ocean Signals
+
+A blue ocean opportunity exists when:
+- Competitors are converging on identical positioning
+- Users are forced to choose based on price because products are indistinguishable
+- A significant user segment is overserved (paying for features they don't use)
+- A significant user segment is underserved (can't afford or can't find a solution)
+
+---
+
+### AI-Native Rethinking
+
+If this product were conceived today with AI capabilities assumed from day one, what changes fundamentally?
+
+#### Categories of AI-Native Innovation
+
+**Anticipatory experiences:**
+The product acts before the user asks. Instead of "search for X," the product surfaces X when the user is likely to need it. This requires understanding user intent from context.
+
+**Natural language as primary interface:**
+Instead of forms, menus, and buttons, the user describes what they want in natural language. The product interprets intent, executes actions, and confirms results. This isn't a chatbot bolted on — it's a fundamentally different interaction model.
+
+**Automated quality and feedback:**
+The product continuously evaluates its own output and the user's work, providing real-time feedback, suggestions, and corrections without being asked.
+
+**Personalization without configuration:**
+The product adapts to each user's patterns, preferences, and context without requiring explicit settings or preferences. The more the user uses it, the better it gets.
+
+#### AI-Native vs. AI-Augmented
+
+- **AI-native**: The product could not exist without AI. The core value proposition depends on AI capabilities.
+- **AI-augmented**: The product exists without AI, but AI makes it better. AI is a feature, not the foundation.
+
+Vision innovation should prioritize AI-native opportunities over AI-augmented ones. AI-augmented features are better suited for PRD innovation.
+
+---
+
+### Evaluation Criteria
+
+For each innovation opportunity, evaluate on four dimensions:
+
+#### Strategic Fit
+- Does it reinforce the vision's core thesis?
+- Does it serve the same target users or adjacent ones?
+- Does it align with the stated guiding principles?
+- Would including it make the vision more coherent or less?
+
+#### Defensibility
+- Is this hard for competitors to replicate?
+- Does it create switching costs, network effects, or data advantages?
+- Does it require capabilities or relationships that take time to build?
+- Would a well-funded competitor need more than money to catch up?
+
+#### Timing
+- Is this a v1 differentiator or a future roadmap item?
+- Are the enabling technologies mature enough to deliver reliably?
+- Is the market ready for this approach, or would it need education?
+- Does this need to be first-mover or can it be fast-follower?
+
+#### Feasibility
+- Can current AI capabilities deliver this reliably?
+- Does the team have the expertise to execute this?
+- Are the required data sources and integrations available?
+- What's the minimum viable version of this innovation?
+
+### Decision Framework
+
+| | High Defensibility | Low Defensibility |
+|---|---|---|
+| **High Strategic Fit** | Must-have for vision | Evaluate timing — good if early-mover |
+| **Low Strategic Fit** | Backlog — may pivot into relevance | Reject — distraction |
+
+---
+
+### Presenting Strategic Innovations
+
+Group innovations by dimension (market, ecosystem, contrarian, AI-native) for structured decision-making. For each innovation:
+
+1. **What**: The strategic innovation in one sentence
+2. **Why**: Strategic rationale tied to the vision's goals or gaps
+3. **Impact**: How much stronger the product positioning becomes (high / medium / low)
+4. **Defensibility**: How hard this is to replicate (high / medium / low)
+5. **Timing**: v1 differentiator or future roadmap
+6. **Recommendation**: Must-have for vision, backlog, or reject
+
+### Example Innovation Finding
+
+```markdown
+## Innovation Finding: Ecosystem Data Benchmark Play
+
+**Dimension:** Ecosystem & Platform
+**Applies to:** Vision section "Market Positioning"
+
+**Current positioning:** The product is a standalone tool for individual teams.
+
+**Proposed strategic shift:** Position as an ecosystem hub that aggregates
+anonymized usage data across customers to provide industry benchmarks.
+Individual teams get better by seeing how they compare to peers.
+
+**Strategic rationale:** Competitors are standalone tools competing on features.
+An ecosystem play creates a data network effect — each new customer makes the
+benchmarks more valuable for all customers, creating a defensibility moat that
+feature competition cannot replicate.
+
+**Impact:** High — transforms positioning from "better tool" to "smarter tool
+that gets better with scale."
+
+**Defensibility:** High — requires critical mass of data that a new entrant
+cannot shortcut.
+
+**Timing:** v1 foundation, v2+ full realization. v1 needs data collection
+infrastructure and basic benchmarks. Full benchmarking suite is a roadmap item.
+
+**Recommendation:** Must-have for vision. Include data collection and basic
+benchmarks in v1 scope. Full benchmark platform is backlog.
+```
+
+---
+
+### Anti-Patterns
+
+- Don't innovate on commodity features (auth, billing, CRUD) — these should be standard
+- Don't propose innovations that require the product to be successful first (network effects for a product with zero users need a bootstrap strategy)
+- Don't confuse "technically interesting" with "strategically valuable"
+- Don't ignore the user's stated vision — innovations should extend it, not replace it
+- Don't conflate strategic innovation with feature requests — "add a dashboard" is a feature, "position as the intelligence layer for the industry" is strategic
+- Don't propose more than 5-7 innovations — decision fatigue reduces quality of choices
+- Don't present all innovations as must-haves — honest triage builds trust and produces better decisions

package/{knowledge → content/knowledge}/tools/post-implementation-review-methodology.md

@@ -44,7 +44,7 @@ Review the whole codebase for systemic concerns:
 Codex and Gemini cannot read files directly. Build a context bundle:
 
 1. Full file tree (excluding node_modules, .git, dist, build, coverage)
-2. Architecture docs (docs/architecture.md, docs/adrs/*.md if present)
+2. Architecture docs (docs/system-architecture.md, docs/adrs/*.md if present)
 3. Coding standards (docs/coding-standards.md)
 4. Up to 15 strategically selected files:
    - Entry points (main.*, index.*, app.*, server.* at root/src level)

package/{pipeline → content/pipeline}/consolidation/workflow-audit.md

@@ -5,7 +5,7 @@ summary: "Audits every document that mentions workflow (CLAUDE.md, git-workflow,
 phase: "consolidation"
 order: 1120
 dependencies: [claude-md-optimization]
-outputs: [CLAUDE.md, docs/git-workflow.md]
+outputs: [CLAUDE.md, docs/git-workflow.md, docs/coding-standards.md, tasks/lessons.md]
 conditional: null
 reads: [operations]
 knowledge-base: [cross-phase-consistency, claude-md-patterns, git-workflow-patterns]

package/{pipeline → content/pipeline}/decisions/review-adrs.md

@@ -31,7 +31,7 @@ independent review validation.
 - docs/reviews/adrs/gemini-review.json (depth 4+, if available) — raw Gemini findings
 
 ## Quality Criteria
-- (mvp) All ADR-specific review passes executed
+- (mvp) Contradiction check executed with findings documented
 - (mvp) Every finding categorized P0-P3 with specific ADR number, section, and issue. Severity definitions: P0 = Breaks downstream work. P1 = Prevents quality milestone. P2 = Known tech debt. P3 = Polish.
 - (deep) Missing decisions identified and documented
 - (mvp) Contradictions resolved

package/{pipeline → content/pipeline}/environment/design-system.md

@@ -5,7 +5,7 @@ summary: "Creates a visual language — color palette (WCAG-compliant), typograp
 phase: "environment"
 order: 320
 dependencies: [dev-env-setup]
-outputs: [docs/design-system.md, tailwind.config.js, docs/coding-standards.md]
+outputs: [docs/design-system.md, docs/coding-standards.md]
 reads: [create-prd]
 conditional: "if-needed"
 knowledge-base: [design-system-tokens]

package/{pipeline → content/pipeline}/finalization/implementation-playbook.md

@@ -4,9 +4,9 @@ description: Create the playbook that AI agents follow during implementation
 summary: "Writes the playbook agents reference during every coding session — task execution order, which docs to read before each task, the TDD loop to follow, quality gates to pass, and the handoff format between agents."
 phase: "finalization"
 order: 1430
-dependencies: [developer-onboarding-guide]
+dependencies: [developer-onboarding-guide, implementation-plan]
 outputs: [docs/implementation-playbook.md]
-reads: [story-tests, create-evals, implementation-plan, database-schema, api-contracts, ux-spec, design-system, system-architecture, tdd, coding-standards, security, operations, domain-modeling, adrs, create-prd, project-structure]
+reads: [story-tests, create-evals, implementation-plan, database-schema, api-contracts, ux-spec, design-system, system-architecture, tdd, coding-standards, security, operations, domain-modeling, adrs, create-prd, project-structure, git-workflow, user-stories]
 conditional: null
 knowledge-base: [implementation-playbook]
 ---

package/{pipeline → content/pipeline}/foundation/tech-stack.md

@@ -41,7 +41,7 @@ about ecosystem maturity, alternatives, and gotchas.
 - (mvp) Every choice is a decision, not a menu of options
 - (mvp) Quick Reference section lists every dependency with version
 - (deep) Each technology choice documents AI compatibility assessment (training data availability, convention strength); total direct dependencies counted and justified
-- (depth 4+) Multi-model recommendations synthesized: Consensus (all models agree), Majority (2+ models agree), or Divergent (models disagree — present to user for decision)
+- (depth 4+) Multi-model findings synthesized: Consensus (all models agree), Majority (2+ models agree), or Divergent (models disagree — present to user for decision)
 
 ## Methodology Scaling
 - **deep**: Comprehensive research with competitive analysis for each category.

package/{pipeline → content/pipeline}/modeling/review-domain-modeling.md

@@ -30,7 +30,7 @@ independent review validation.
 - docs/reviews/domain-modeling/gemini-review.json (depth 4+, if available) — raw Gemini findings
 
 ## Quality Criteria
-- (mvp) All review passes executed with findings documented
+- (mvp) Consistency check executed with blocking issues documented
 - (mvp) Every finding categorized by severity (P0-P3). Severity definitions: P0 = Breaks downstream work. P1 = Prevents quality milestone. P2 = Known tech debt. P3 = Polish.
 - (mvp) Fix plan created for P0 and P1 findings
 - (mvp) Fixes applied and re-validated