agile-context-engineering 0.1.0 → 0.2.1

package/agile-context-engineering/templates/wiki/testing-framework.xml

@@ -0,0 +1,283 @@
+<!-- Credits: Testing template content adapted from GSD (Get Shit Done) by @raisiqueira -->
+<!-- Original source: .gsd/get-shit-done/templates/codebase/testing.md -->
+
+<testing-framework>
+    <purpose>
+        Template for `.docs/wiki/testing-framework.md` — captures test framework, patterns, and
+        conventions for the project. Answers "How do I write and run tests that match existing patterns?"
+
+        **Purpose:** Document how tests are written and run. Guide for adding tests that match
+        existing patterns.
+    </purpose>
+
+    <template>
+        <test-framework>
+            ## Test Framework
+
+            **Runner:**
+            - [Framework: e.g., "Jest 29.x", "Vitest 1.x"]
+            - [Config: e.g., "jest.config.js in project root"]
+
+            **Assertion Library:**
+            - [Library: e.g., "built-in expect", "chai"]
+            - [Matchers: e.g., "toBe, toEqual, toThrow"]
+
+            **Run Commands:**
+            ```bash
+            [e.g., "npm test" or "npm run test"]              # Run all tests
+            [e.g., "npm test -- --watch"]                     # Watch mode
+            [e.g., "npm test -- path/to/file.test.ts"]       # Single file
+            [e.g., "npm run test:coverage"]                   # Coverage report
+            ```
+        </test-framework>
+
+        <test-file-organization>
+            ## Test File Organization
+
+            **Location:**
+            - [Pattern: e.g., "*.test.ts alongside source files"]
+            - [Alternative: e.g., "__tests__/ directory" or "separate tests/ tree"]
+
+            **Naming:**
+            - [Unit tests: e.g., "module-name.test.ts"]
+            - [Integration: e.g., "feature-name.integration.test.ts"]
+            - [E2E: e.g., "user-flow.e2e.test.ts"]
+
+            **Structure:**
+            ```
+            [Show actual directory pattern, e.g.:
+            src/
+              lib/
+                utils.ts
+                utils.test.ts
+              services/
+                user-service.ts
+                user-service.test.ts
+            ]
+            ```
+        </test-file-organization>
+
+        <test-structure>
+            ## Test Structure
+
+            **Suite Organization:**
+            ```typescript
+            [Show actual pattern used, e.g.:
+
+            describe('ModuleName', () => {
+              describe('functionName', () => {
+                it('should handle success case', () => {
+                  // arrange
+                  // act
+                  // assert
+                });
+
+                it('should handle error case', () => {
+                  // test code
+                });
+              });
+            });
+            ]
+            ```
+
+            **Patterns:**
+            - [Setup: e.g., "beforeEach for shared setup, avoid beforeAll"]
+            - [Teardown: e.g., "afterEach to clean up, restore mocks"]
+            - [Structure: e.g., "arrange/act/assert pattern required"]
+        </test-structure>
+
+        <mocking>
+            ## Mocking
+
+            **Framework:**
+            - [Tool: e.g., "Jest built-in mocking", "Vitest vi", "Sinon"]
+            - [Import mocking: e.g., "vi.mock() at top of file"]
+
+            **Patterns:**
+            ```typescript
+            [Show actual mocking pattern, e.g.:
+
+            // Mock external dependency
+            vi.mock('./external-service', () => ({
+              fetchData: vi.fn()
+            }));
+
+            // Mock in test
+            const mockFetch = vi.mocked(fetchData);
+            mockFetch.mockResolvedValue({ data: 'test' });
+            ]
+            ```
+
+            **What to Mock:**
+            - [e.g., "External APIs, file system, database"]
+            - [e.g., "Time/dates (use vi.useFakeTimers)"]
+            - [e.g., "Network calls (use mock fetch)"]
+
+            **What NOT to Mock:**
+            - [e.g., "Pure functions, utilities"]
+            - [e.g., "Internal business logic"]
+        </mocking>
+
+        <fixtures-and-factories>
+            ## Fixtures and Factories
+
+            **Test Data:**
+            ```typescript
+            [Show pattern for creating test data, e.g.:
+
+            // Factory pattern
+            function createTestUser(overrides?: Partial&lt;User&gt;): User {
+              return {
+                id: 'test-id',
+                name: 'Test User',
+                email: 'test@example.com',
+                ...overrides
+              };
+            }
+
+            // Fixture file
+            // tests/fixtures/users.ts
+            export const mockUsers = [/* ... */];
+            ]
+            ```
+
+            **Location:**
+            - [e.g., "tests/fixtures/ for shared fixtures"]
+            - [e.g., "factory functions in test file or tests/factories/"]
+        </fixtures-and-factories>
+
+        <coverage>
+            ## Coverage
+
+            **Requirements:**
+            - [Target: e.g., "80% line coverage", "no specific target"]
+            - [Enforcement: e.g., "CI blocks &lt;80%", "coverage for awareness only"]
+
+            **Configuration:**
+            - [Tool: e.g., "built-in coverage via --coverage flag"]
+            - [Exclusions: e.g., "exclude *.test.ts, config files"]
+
+            **View Coverage:**
+            ```bash
+            [e.g., "npm run test:coverage"]
+            [e.g., "open coverage/index.html"]
+            ```
+        </coverage>
+
+        <test-types>
+            ## Test Types
+
+            **Unit Tests:**
+            - [Scope: e.g., "test single function/class in isolation"]
+            - [Mocking: e.g., "mock all external dependencies"]
+            - [Speed: e.g., "must run in &lt;1s per test"]
+
+            **Integration Tests:**
+            - [Scope: e.g., "test multiple modules together"]
+            - [Mocking: e.g., "mock external services, use real internal modules"]
+            - [Setup: e.g., "use test database, seed data"]
+
+            **E2E Tests:**
+            - [Framework: e.g., "Playwright for E2E"]
+            - [Scope: e.g., "test full user flows"]
+            - [Location: e.g., "e2e/ directory separate from unit tests"]
+        </test-types>
+
+        <common-patterns>
+            ## Common Patterns
+
+            **Async Testing:**
+            ```typescript
+            [Show pattern, e.g.:
+
+            it('should handle async operation', async () => {
+              const result = await asyncFunction();
+              expect(result).toBe('expected');
+            });
+            ]
+            ```
+
+            **Error Testing:**
+            ```typescript
+            [Show pattern, e.g.:
+
+            it('should throw on invalid input', () => {
+              expect(() => functionCall()).toThrow('error message');
+            });
+
+            // Async error
+            it('should reject on failure', async () => {
+              await expect(asyncCall()).rejects.toThrow('error message');
+            });
+            ]
+            ```
+
+            **Snapshot Testing:**
+            - [Usage: e.g., "for React components only" or "not used"]
+            - [Location: e.g., "__snapshots__/ directory"]
+        </common-patterns>
+    </template>
+
+    <guidelines>
+
+        **What belongs in testing-framework.md:**
+        - Test framework and runner configuration
+        - Test file location and naming patterns
+        - Test structure (describe/it, beforeEach patterns)
+        - Mocking approach and examples
+        - Fixture/factory patterns
+        - Coverage requirements
+        - How to run tests (commands)
+        - Common testing patterns in actual code
+
+        **What does NOT belong here:**
+        - Specific test cases (defer to actual test files)
+        - Technology choices (that's system-architecture.md)
+        - CI/CD setup (that's deployment docs)
+
+        **When filling this template:**
+        - Check package.json scripts for test commands
+        - Find test config file (jest.config.js, vitest.config.ts)
+        - Read 3-5 existing test files to identify patterns
+        - Look for test utilities in tests/ or test-utils/
+        - Check for coverage configuration
+        - Document actual patterns used, not ideal patterns
+
+        **Useful for story planning when:**
+        - Adding new features (write matching tests)
+        - Refactoring (maintain test patterns)
+        - Fixing bugs (add regression tests)
+        - Understanding verification approach
+        - Setting up test infrastructure
+
+        **Analysis approach:**
+        - Check package.json for test framework and scripts
+        - Read test config file for coverage, setup
+        - Examine test file organization (collocated vs separate)
+        - Review 5 test files for patterns (mocking, structure, assertions)
+        - Look for test utilities, fixtures, factories
+        - Note any test types (unit, integration, e2e)
+        - Document commands for running tests
+
+    </guidelines>
+
+    <evolution>
+
+        Update when testing patterns or framework changes.
+
+        **Update triggers:**
+        - Test framework or runner changed (e.g., Jest to Vitest)
+        - Mocking approach changed
+        - New test type introduced (e.g., adding E2E tests)
+        - Coverage requirements changed
+        - Test file organization restructured
+        - New test utilities or factories added
+
+        **NOT an update trigger:**
+        - New test files added following existing patterns
+        - Individual test case additions
+        - Bug fixes in test code
+
+    </evolution>
+
+</testing-framework>

package/agile-context-engineering/templates/wiki/wiki-readme.xml

@@ -0,0 +1,276 @@
+<wiki-readme>
+    <purpose>
+        Template for `.docs/wiki/wiki-readme.md` — the entry point and usage guide for the
+        engineering wiki. Generated once when the `.docs/wiki/` directory is first created
+        (typically by `/ace:map-system`).
+
+        Serves two audiences:
+        - **Humans** who want to understand, navigate, and contribute to the wiki
+        - **AI agents** who need to know which documents to load for a given task
+
+        This is NOT a documentation template — it is a META-DOCUMENT that describes how the
+        wiki itself works. Think of it as the README for the wiki system.
+    </purpose>
+
+    <template>
+        <header>
+            # Engineering Wiki
+
+            Living knowledge base for this codebase. Maintained by AI agents after each story
+            and by developers when making structural changes.
+
+            **For humans**: browse by subsystem, read system and pattern docs to understand how things work.
+            **For AI agents**: load the minimal set of docs needed for your current task — every token counts.
+        </header>
+
+        <directory-structure>
+            ## Directory Structure
+
+            ```
+            .docs/wiki/
+            |-- wiki-readme.md                          # This file — how to use the wiki
+            |-- system-wide/                            # Documents that span all subsystems
+            |   |-- system-structure.md                 # Physical layout, subsystem index, shared dirs
+            |   |-- system-architecture.md              # L1/L2 C4 views, core flows, tech stack
+            |   |-- testing-framework.md                # Test runner, patterns, conventions
+            |   |-- coding-standards.md                 # Language and paradigm-specific rules
+            |   `-- tech-debt-index.md                  # Roll-up of all known tech debt
+            `-- subsystems/
+                `-- [subsystem-name]/                    # One folder per subsystem
+                    |-- structure.md                     # File layout, "where to add code"
+                    |-- architecture.md                  # L3 components, internal flows, dependencies
+                    |-- systems/                         # WHAT exists — domain system docs
+                    |   `-- [system-name].md
+                    |-- patterns/                        # HOW to implement — reusable structural patterns
+                    |   `-- [pattern-name].md
+                    |-- cross-cutting/                   # Shared infrastructure spanning systems
+                    |   `-- [concern-name].md
+                    |-- guides/                          # Step-by-step implementation recipes
+                    |   `-- [task-name].md
+                    `-- decisions/                       # WHY — Architecture Decision Records
+                        `-- ADR-NNN-[slug].md
+            ```
+        </directory-structure>
+
+        <document-types>
+            ## Document Types
+
+            ### System-Wide Documents
+
+            | Document | Answers | Created By |
+            |----------|---------|------------|
+            | `system-structure.md` | What subsystems exist and where do they live? | `/ace:map-system` |
+            | `system-architecture.md` | What's the system design, tech stack, and core flows? | `/ace:map-system` |
+            | `testing-framework.md` | How do we test? Runner, patterns, conventions. | `/ace:map-system` |
+            | `coding-standards.md` | What are the mandatory code quality rules? | `/ace:init-coding-standards` |
+            | `tech-debt-index.md` | What known quality issues exist across the codebase? | `/ace:map-story` (auto) |
+
+            ### Subsystem Documents
+
+            | Document | Answers | Created By |
+            |----------|---------|------------|
+            | `structure.md` | Where do files live in this subsystem? Where do I add new code? | `/ace:map-subsystem` |
+            | `architecture.md` | What are the internal components, layers, and flows? | `/ace:map-subsystem` |
+
+            ### Knowledge Documents (per subsystem)
+
+            | Category | Answers | When to Create |
+            |----------|---------|----------------|
+            | `systems/` | How does this domain system work RIGHT NOW? | One doc per coherent domain capability (e.g., drawing system, order processing) |
+            | `patterns/` | How do I implement using this reusable pattern? | When a structural pattern appears in 2+ implementations |
+            | `cross-cutting/` | How does this shared infrastructure work? | For concerns spanning multiple domain systems (DI, events, registry) |
+            | `guides/` | How do I perform this recurring task end-to-end? | When a task is repeated (adding a new tool, endpoint, entity) |
+            | `decisions/` | Why was this significant choice made? | When a meaningful trade-off was evaluated and decided |
+        </document-types>
+
+        <how-to-use>
+            ## How to Use This Wiki
+
+            ### For Humans
+
+            **Understand a subsystem:**
+            1. Read `subsystems/[name]/architecture.md` — components, layers, internal flows
+            2. Read relevant `systems/*.md` — domain systems you care about
+            3. Follow cross-references to patterns and cross-cutting concerns
+
+            **Implement a new feature:**
+            1. Read `system-wide/coding-standards.md` — mandatory rules
+            2. Read the subsystem's `structure.md` — where to add files
+            3. Check `guides/` — there may be a step-by-step recipe for your task
+            4. Read relevant `patterns/` — follow established structural patterns
+            5. Check `decisions/` — respect past architectural decisions
+
+            **Debug or investigate:**
+            1. Start with the relevant `systems/*.md` — it has entry points, flows, and components
+            2. Follow the sequence diagrams to trace data flow
+            3. Check `cross-cutting/` for shared infrastructure behavior
+
+            ### For AI Agents
+
+            **Context loading strategy:**
+            - ALWAYS load system-wide docs first: `system-structure.md`, `system-architecture.md`, `coding-standards.md`, `testing-framework.md`
+            - Then load subsystem docs for the subsystem(s) you are modifying
+            - Load ONLY the `systems/`, `patterns/`, `cross-cutting/`, and `guides/` docs relevant to your task
+            - Check `decisions/` for ADRs that constrain your design choices
+            - Every token in your context window costs reasoning capacity — load less, reason better
+
+            **Finding the right docs:**
+            - Story files include a `## Relevant Wiki` section with curated doc references
+            - Each doc cross-references related docs via markdown links — follow them as needed
+            - `structure.md` → where files live; `architecture.md` → how things connect
+            - `systems/` → domain behavior; `patterns/` → structural recipes; `guides/` → task recipes
+        </how-to-use>
+
+        <how-to-create>
+            ## Creating New Wiki Documents
+
+            Wiki documents are primarily created and updated by AI agents (ace-wiki-mapper) through:
+            - `/ace:map-system` — system-wide documents
+            - `/ace:map-subsystem` — subsystem structure, architecture, and knowledge docs
+            - `/ace:map-story` — updates knowledge docs after story implementation
+
+            ### Manual Creation Guidelines
+
+            If creating a document manually, follow these rules:
+
+            **Naming:**
+            - Use kebab-case for all file names: `drawing-system.md`, `repository-pattern.md`
+            - Systems: name after the domain capability — `drawing-system.md`, `order-processing.md`
+            - Patterns: name after the pattern — `template-method-pattern.md`, `repository-pattern.md`
+            - Cross-cutting: name after the concern — `dependency-injection.md`, `event-system.md`
+            - Guides: name after the task — `adding-drawing-tool.md`, `adding-crud-endpoint.md`
+            - Decisions: `ADR-NNN-kebab-slug.md` — sequential numbering within the subsystem
+
+            **Content rules:**
+            - EXTREMELY SUCCINCT — every word must add value
+            - Bullet points over paragraphs
+            - Code references: `file-path:ClassName.methodName` — never line numbers
+            - All architecture diagrams MUST be mermaid (flowchart, classDiagram, sequenceDiagram)
+            - File trees: ASCII only (`|--` and backtick for last item)
+            - Inline code ONLY for interface/type contracts
+            - Cross-reference related docs with markdown links
+            - Every `systems/*.md` MUST have at least one mermaid sequenceDiagram
+
+            **Topic-scoped, not story-scoped:**
+            - Documents describe a CONCERN, not a story or sprint
+            - "How does the drawing system work?" — good
+            - "What story #19 implemented" — wrong (that goes in `.ace/artifacts/`)
+
+            **Create vs update decision:**
+            1. Does an existing doc already cover this topic? → UPDATE it
+            2. Could this be a new section in an existing doc? → Add the section
+            3. Any overlap with existing docs? → Merge into the existing doc
+            4. Genuinely new topic with no overlap? → CREATE a new doc
+        </how-to-create>
+
+        <keeping-current>
+            ## Keeping the Wiki Current
+
+            ### Automatic Updates
+
+            After each story implementation, `/ace:map-story` analyzes git changes and updates
+            the relevant knowledge documents. This is the primary mechanism for keeping the wiki
+            current.
+
+            ### Manual Update Triggers
+
+            **Update `system-structure.md` when:**
+            - New subsystem added, removed, or merged
+            - Shared directory added or removed
+            - Workspace configuration changed
+
+            **Update `system-architecture.md` when:**
+            - New subsystem or external integration added
+            - Communication pattern changed
+            - Tech stack changed
+
+            **Update `testing-framework.md` when:**
+            - Test runner or mocking approach changed
+            - Coverage requirements changed
+
+            **Update subsystem `structure.md` when:**
+            - Top-level directory added, renamed, or removed within the subsystem
+
+            **Update subsystem `architecture.md` when:**
+            - New architectural layer or component type introduced
+            - New inbound or outbound dependency added
+
+            **Update knowledge docs when:**
+            - `systems/` — new component, behavior, entry point, or integration point
+            - `patterns/` — new implementation added, pattern structure changed
+            - `cross-cutting/` — new registration, mechanism changed
+            - `guides/` — new step required, step order changed, reference implementation changed
+            - `decisions/` — NEVER edit accepted ADRs; create a new one that supersedes
+
+            ### Tech Debt
+
+            Tech debt items are tracked in individual `systems/` and `cross-cutting/` docs (## Tech Debt section)
+            and rolled up in `system-wide/tech-debt-index.md`. Items are removed when fixed.
+        </keeping-current>
+
+        <subsystem-index>
+            ## Subsystems
+
+            [POPULATE FROM system-structure.md — list each subsystem with link to its wiki folder]
+
+            | Subsystem | Wiki Path | Responsibility |
+            |-----------|-----------|----------------|
+            | [name] | [subsystems/name/](subsystems/name/) | [one-line responsibility] |
+        </subsystem-index>
+    </template>
+
+    <guidelines>
+
+        **This is a META-DOCUMENT, not a code documentation template.**
+        It describes the wiki system itself — its structure, conventions, and usage.
+        It does NOT contain code references, mermaid diagrams, or architectural content.
+
+        **Populating the template:**
+        - The Directory Structure section is FIXED — it describes the standard wiki layout.
+          Do NOT customize it per project. It shows the canonical structure.
+        - The Document Types tables are FIXED — they describe what each document type is.
+        - The Subsystems table at the bottom MUST be populated from `system-structure.md`
+          (the subsystem index). If `system-structure.md` doesn't exist yet, leave the table
+          with placeholder rows and a note to populate after `/ace:map-system`.
+        - All wiki paths in the Subsystems table should be relative links from the wiki root.
+
+        **Tone:**
+        - Direct and practical — this is a reference, not a tutorial
+        - Written for two audiences in parallel: humans and AI agents
+        - Short sentences, bullet points, tables over prose
+        - No filler, no motivational text, no history
+
+        **What does NOT belong here:**
+        - Actual code documentation (that lives in the wiki docs themselves)
+        - Project-specific architecture details (that's system-architecture.md)
+        - Process details about ACE workflows (that's internal to the tool)
+        - Story or feature information
+        - Revision history
+
+    </guidelines>
+
+    <evolution>
+
+        This document is MOSTLY STABLE — it describes the wiki system, which rarely changes.
+
+        **Update triggers:**
+        - New document type added to the wiki system (e.g., a new knowledge category)
+        - New subsystem mapped (update the Subsystems table)
+        - Subsystem removed or renamed (update the Subsystems table)
+        - Wiki conventions changed (naming rules, diagram rules, reference format)
+
+        **NOT an update trigger:**
+        - New documents created within existing categories
+        - Content updates to any wiki document
+        - New stories, features, or sprints
+        - Changes to ACE tool internals
+
+        **Update rules:**
+        - UPDATE the Subsystems table when subsystems are added/removed
+        - The rest of the document should rarely need changes
+        - If the wiki structure itself evolves (new folders, new doc types), update the
+          Directory Structure and Document Types sections
+
+    </evolution>
+
+</wiki-readme>

package/agile-context-engineering/utils/questioning.xml

@@ -0,0 +1,111 @@
+<!--
+The contents of this file are taken from GSD project
+All credits go to: https://github.com/gsd-build/get-shit-done
+-->
+<questioning-guide>
+    <purpose>Help the user discover and articulate what they want to build by doing collaborative thinking.</purpose>
+
+    <philosophy>
+        **You are a thinking partner, not an interviewer.**
+        The user often starts from a rough and fuzzy idea. Your job is to help them sharpen it.
+        Ask questions that make them think "oh, I hadn't considered that" or "yes, that's exactly what I mean."
+        Don't interrogate. Collaborate. Don't follow a script. Follow the thread.
+    </philosophy>
+
+    <how-to-question>
+        **Start open.** Let them dump their mental model. Don't interrupt with structure.
+        **Follow energy.** Whatever they emphasized, dig into that. What excited them? What problem sparked this?
+        **Challenge vagueness.** Never accept fuzzy answers. "Good" means what? "Users" means who? "Simple" means how?
+        **Make the abstract concrete.** "Walk me through using this." "What does that actually look like?"
+        **Clarify ambiguity.** "When you say Z, do you mean A or B?" "You mentioned X — tell me more."
+        **Know when to stop.** When you understand what they want, why they want it, who it's for, and what done looks like — offer to proceed.
+    </how-to-question>
+
+    <question-types>
+        Use these as inspiration, not a checklist. Pick what's relevant to the thread.
+
+        **Motivation — why this exists:**
+        - "What prompted this?"
+        - "What are you doing today that this replaces?"
+        - "What would you do if this existed?"
+
+        **Concreteness — what it actually is:**
+        - "Walk me through using this"
+        - "You said X — what does that actually look like?"
+        - "Give me an example"
+
+        **Clarification — what they mean:**
+        - "When you say Z, do you mean A or B?"
+        - "You mentioned X — tell me more about that"
+
+        **Success — how you'll know it's working:**
+        - "How will you know this is working?"
+        - "What does done look like?"
+    </question-types>
+
+    <using-askuserquestion-tool>
+
+        Use AskUserQuestion to help users think by presenting concrete options to react to.
+
+        **Good options:**
+        - Interpretations of what they might mean
+        - Specific examples to confirm or deny
+        - Concrete choices that reveal priorities
+
+        **Bad options:**
+        - Generic categories ("Technical", "Business", "Other")
+        - Leading options that presume an answer
+        - Too many options (2-4 is ideal)
+
+        **Example — vague answer:**
+        User says "it should be fast"
+
+        - header: "Fast"
+        - question: "Fast how?"
+        - options: ["Sub-second response", "Handles large datasets", "Quick to build", "Let me explain"]
+
+        **Example — following a thread:**
+        User mentions "frustrated with current tools"
+
+        - header: "Frustration"
+        - question: "What specifically frustrates you?"
+        - options: ["Too many clicks", "Missing features", "Unreliable", "Let me explain"]
+
+    </using-askuserquestion-tool>
+
+    <context-checklist>
+        Use this as a **background checklist**, not a conversation structure. Check these mentally as you go. If gaps remain, weave questions naturally.
+
+        - [ ] What they're building (concrete enough to explain to a stranger)
+        - [ ] Why it needs to exist (the problem or desire driving it)
+        - [ ] Who it's for (even if just themselves)
+        - [ ] What "done" looks like (observable outcomes)
+
+        Four things. If they volunteer more, capture it.
+    </context-checklist>
+
+    <decision-gate>
+        When you could write a clear product-vision.md, offer to proceed:
+
+        - header: "Ready?"
+        - question: "I think I understand what you're after. Ready to create product-vision.md?"
+        - options:
+        - "Create product-vision.md" — Let's move forward
+        - "Keep exploring" — I want to share more / ask me more
+
+        If "Keep exploring" — ask what they want to add or identify gaps and probe naturally.
+
+        Loop until "Create product-vision.md" selected.
+    </decision-gate>
+
+    <anti-patterns>
+        - **Checklist walking** — Going through domains regardless of what they said
+        - **Canned questions** — "What's your core value?" "What's out of scope?" regardless of context
+        - **Corporate speak** — "What are your success criteria?" "Who are your stakeholders?"
+        - **Interrogation** — Firing questions without building on answers
+        - **Rushing** — Minimizing questions to get to "the work"
+        - **Shallow acceptance** — Taking vague answers without probing
+        - **Premature constraints** — Asking about tech stack before understanding the idea
+    </anti-patterns>
+
+</questioning-guide>