forge-server 0.1.0

package/plugin/skills/implementation-execution/SKILL.md

@@ -0,0 +1,291 @@
+---
+name: implementation-execution
+description: This skill should be used when executing an implementation plan -- writing code, building features, creating modules. Used by frontend-specialist, backend-specialist, and data-specialist agents to follow plans with discipline and quality.
+user-invocable: false
+---
+
+# Implementation Execution Skill
+
+## Purpose
+
+Provide a disciplined, quality-focused methodology for executing implementation plans. Apply this skill when writing code, building features, creating modules, or implementing any concrete deliverable from an architecture or design plan. The methodology ensures that implementation agents produce real, working, connected code -- never stubs, never placeholders, never "implement later" shortcuts.
+
+---
+
+## Pre-Implementation: Read Before Writing
+
+### Read the Full Plan
+
+Before writing a single line of code, read the ENTIRE plan document that governs this implementation task. Not just the section relevant to the current module -- the full plan, including:
+
+- **Vision document**: Understand the "why" behind every requirement.
+- **Requirements document**: Understand the specific acceptance criteria.
+- **Architecture document**: Understand the module boundaries, API contracts, data models, and integration points.
+- **XD plan** (if frontend): Understand the design system, component hierarchy, and interaction patterns.
+
+Do not skim. Do not read only the section assigned. Context from other sections prevents integration failures.
+
+### Read the Project CLAUDE.md
+
+Before starting implementation, read the project's `CLAUDE.md` file (if one exists) and the user's global `CLAUDE.md`. These contain learned gotchas, stack-specific traps, and patterns that are not obvious from the codebase alone. Apply every relevant gotcha.
+
+**Known critical gotchas to internalize**:
+- SWC hoists all `require()` above executable code -- never read `process.env` at module top-level.
+- Use lazy initialization (Proxy or getter) for anything that reads environment variables.
+- `dotenv.config()` must execute in `main.ts` before NestJS bootstrap.
+- Default imports for `jwks-rsa` and `jsonwebtoken`, not namespace imports.
+- `postgres` (postgres.js) driver, not `pg`.
+- `db:generate` before `db:migrate` -- no auto-generate.
+- Export interfaces used as service return types.
+
+### Read the Existing Codebase
+
+Before creating any new file, use the **project-discovery** skill (or its key steps) to understand:
+- Naming conventions in the existing codebase.
+- File organization patterns.
+- Import patterns (aliases, barrel exports).
+- Error handling patterns.
+- Testing patterns.
+
+New code must match existing patterns exactly. Do not introduce new conventions unless the plan explicitly calls for it.
+
+---
+
+## Implementation Methodology: Incremental Build
+
+### Build the Smallest Working Unit First
+
+Never attempt to build an entire feature in one pass. Break the work into the smallest unit that can independently compile and be verified:
+
+1. **Schema first**: If the feature needs database tables, define the Drizzle schema and generate the migration. Verify the migration applies cleanly.
+2. **Service layer second**: Write the service that queries the schema. Verify it compiles and the types resolve.
+3. **Controller third**: Write the controller that exposes the service. Verify the route registers and returns data.
+4. **Integration fourth**: Wire the module into the app module. Verify end-to-end request flow.
+5. **Frontend last** (if applicable): Build the UI that calls the API. Verify the full stack works together.
+
+At each step, verify before proceeding. Do not stack unverified layers.
+
+### Verification at Each Step
+
+After completing each incremental unit:
+- **Compile check**: Does `tsc --noEmit` pass? Does the project build without errors?
+- **Runtime check**: Does the application start? Does the new route/module register?
+- **Functional check**: Does the feature return correct data for a basic happy-path case?
+- **Test check**: Does the corresponding test pass?
+
+If any check fails, fix it before moving to the next unit. Do not accumulate failures.
+
+---
+
+## Anti-Stub Discipline
+
+This is the most critical rule of implementation execution. Violations are treated as blockers.
+
+### What Constitutes a Stub
+
+A stub is any code that does not perform its stated function. This includes:
+
+- Functions that return hardcoded values instead of querying real data sources.
+- API endpoints that return mock JSON instead of calling real services.
+- Components that render placeholder text ("Lorem ipsum," "Coming soon," "TODO") instead of real content.
+- Error handlers that catch and swallow errors, log nothing, and return generic messages.
+- Services that call `console.log` instead of performing real operations.
+- Database queries that are commented out with a hardcoded return value.
+- Any code containing `TODO`, `FIXME`, `HACK`, `XXX`, or `PLACEHOLDER` in production files.
+- Test files that contain `it.skip`, `it.todo`, or empty test bodies.
+
+### The Anti-Stub Standard
+
+Every function must perform its real operation:
+- **API endpoints** must call real services, which call real data stores, and return real data.
+- **Services** must contain real business logic, real validation, real error handling.
+- **Components** must render real content from real data sources with real styling.
+- **Error handlers** must catch specific error types, log meaningful messages, and return appropriate HTTP status codes with descriptive error bodies.
+- **Tests** must make real assertions against real behavior. A test that always passes is worse than no test.
+
+### When Partial Implementation Is Acceptable
+
+The only acceptable form of incomplete code is when the plan explicitly stages work across phases and a later phase will complete the implementation. In this case:
+- The incomplete code must still compile and not break the application.
+- The incomplete area must be documented in the plan's "Remaining Work" section.
+- The code must NOT contain `TODO` comments -- instead, the plan document tracks what remains.
+
+---
+
+## Connection Verification
+
+After building any component, verify that it connects correctly to adjacent components.
+
+### Backend Connection Checks
+
+- After writing a service, verify the controller can call it and return data.
+- After writing a controller, verify the module exports it and the route is reachable.
+- After writing a database schema, verify the service can query it and the types align.
+- After writing a guard or interceptor, verify it is applied to the correct routes and functions correctly.
+- After writing a module, verify it is imported by the app module (or a parent feature module) and its providers resolve.
+
+### Frontend Connection Checks
+
+- After writing an API client function, verify it calls the correct backend endpoint with the correct method and payload.
+- After writing a component, verify it receives the correct props and renders the correct data.
+- After writing a state manager (store, context, reducer), verify components read and write state correctly.
+- After writing a route, verify navigation reaches the correct component with the correct parameters.
+
+### Cross-Stack Connection Checks
+
+- After writing a backend endpoint, verify the frontend API client calls it correctly.
+- After changing a response shape, verify the frontend type definitions and rendering logic are updated.
+- After changing a database schema, verify the service queries, DTOs, and API contracts are updated.
+
+Never assume connections work. Verify explicitly by reading both sides of every integration boundary.
+
+---
+
+## File Creation Discipline
+
+### Prefer Editing Existing Files
+
+Before creating a new file, check whether an existing file should be modified instead. Common mistakes:
+- Creating a new utility file when an existing `utils/` module already has a similar function.
+- Creating a new DTO file when the existing DTO file for that module should be extended.
+- Creating a new test file when the existing test file should have additional test cases.
+
+### When New Files Are Necessary
+
+Create new files only when:
+- The plan explicitly calls for a new module, service, controller, or component.
+- The existing file would become too large (> 300 lines) with the addition.
+- The new code has a distinctly different responsibility from the existing file.
+
+### File Naming
+
+Follow the project's existing naming conventions exactly. If the project uses:
+- `kebab-case.service.ts` -- use that pattern.
+- `PascalCase.controller.ts` -- use that pattern.
+- `{feature}.{type}.ts` -- use that pattern.
+
+Never introduce a new naming convention. Match what exists.
+
+---
+
+## Import Hygiene
+
+### Verify All Imports Resolve
+
+After writing or modifying any file, verify that:
+- Every import statement references a file that exists.
+- Every imported symbol is exported by the source file.
+- No circular dependencies are introduced (Module A imports B which imports A).
+
+### Import Order Convention
+
+Follow the project's existing import order. If no convention exists, use:
+1. Node.js built-in modules (`fs`, `path`, `crypto`)
+2. External packages (`@nestjs/core`, `drizzle-orm`)
+3. Internal shared modules (`@/common`, `@/shared`)
+4. Local module imports (`./dto`, `./service`)
+
+Separate each group with a blank line.
+
+### Barrel Export Maintenance
+
+If the project uses barrel exports (`index.ts`), update them when adding new exports. A new service, DTO, or component that is not added to its module's barrel export will cause import failures in consuming modules.
+
+---
+
+## Error Handling
+
+### Real Error Handling Standards
+
+Every function that can fail must handle failure explicitly:
+
+- **Database queries**: Catch connection errors, constraint violations, and not-found conditions. Return appropriate error responses for each.
+- **External API calls**: Handle timeout, 4xx, 5xx, and network failure cases. Implement retry logic where appropriate (with exponential backoff, not infinite retries).
+- **User input**: Validate all input at the controller layer using DTOs with class-validator decorators (or the project's validation approach). Never trust client input.
+- **Business logic**: Throw typed exceptions (`NotFoundException`, `ConflictException`, `ForbiddenException`) that map to correct HTTP status codes.
+- **Async operations**: Handle promise rejections. Never leave an `async` function without error handling on awaited calls.
+
+### What NOT to Do
+
+- Never catch an error and return a generic "Something went wrong" message.
+- Never catch an error and silently swallow it (`catch (e) {}`).
+- Never use `console.log` as the sole error handling mechanism.
+- Never throw raw `Error` objects when a typed NestJS exception is appropriate.
+
+---
+
+## Reporting
+
+After completing an implementation unit (a module, a feature, or a phase), write a brief implementation report as a terminal message using the **terminal-presentation** skill:
+
+```
+--- {AGENT ROLE} ---
+Phase: Implementation
+Status: {Complete | In Progress | Blocked}
+
+## Built
+- {Module/feature name}: {One-line description of what it does}
+- {Module/feature name}: {One-line description of what it does}
+
+## Connections Verified
+- {Endpoint} -> {Service} -> {Database}: Working
+- {Component} -> {API Client} -> {Endpoint}: Working
+
+## Tests
+- {Test file}: {N} tests passing
+
+## Remaining
+- {What is left to build, if anything}
+
+---
+```
+
+---
+
+## Testing Alongside Implementation
+
+Write tests immediately after completing each unit, not all tests at the end.
+
+### Test-per-Unit Pattern
+
+1. Build the schema. Write a test that verifies the schema compiles and migrations apply.
+2. Build the service. Write a test that verifies the service returns correct data for happy-path and error cases.
+3. Build the controller. Write a test that verifies HTTP requests return correct responses.
+4. Build the component. Write a test that verifies rendering with expected props.
+
+### Test Quality Standards
+
+- Every test must make at least one meaningful assertion.
+- Tests must fail if the implementation is wrong. Write the assertion first, verify it would fail with a stub, then verify it passes with real code.
+- Use realistic test data, not `{ id: 1, name: 'test' }`. Use data that resembles production (real names, real email formats, realistic quantities).
+- Mock only external boundaries (database, HTTP clients, third-party services). Do not mock the code under test.
+- For NestJS services, use the Proxy-based Drizzle mock pattern established in the project (if applicable) for chainable query mocking.
+
+---
+
+## The "Done" Standard
+
+Never claim "done" without meeting ALL of these criteria:
+
+1. **The code compiles** without errors (`tsc --noEmit` or equivalent).
+2. **The application starts** without runtime errors.
+3. **All tests pass** -- both new tests and existing tests.
+4. **Connections are verified** -- every integration boundary has been checked.
+5. **No stubs remain** -- a search for TODO, FIXME, placeholder, mock (in production code), stub, hardcoded returns zero results in the implementation.
+6. **The implementation matches the plan** -- every requirement in the assigned section is implemented.
+7. **An implementation report has been written** -- the team knows what was built and what it connects to.
+
+If any criterion is not met, the work is not done. Fix it before reporting completion.
+
+---
+
+## Anti-Patterns to Avoid
+
+- **Plan deviation without approval**: Never implement something different from what the plan specifies. If the plan is wrong, raise it with the Architect -- do not silently diverge.
+- **Big-bang implementation**: Never write an entire feature before compiling or testing. Build incrementally.
+- **Copy-paste without understanding**: Never copy code from another module without understanding what it does and adapting it to the current context.
+- **Optimizing prematurely**: Build for correctness first. Optimize only when the plan calls for it or profiling reveals a bottleneck.
+- **Ignoring existing patterns**: Never introduce a new way of doing something that the codebase already does a different way. Match existing patterns.
+- **Claiming done without running**: Never report completion based on reading the code. Run it. Test it. Verify it.
+- **Swallowing errors to make tests pass**: If a test fails, fix the implementation, not the test. If the test is wrong, fix the test with a comment explaining why, not by deleting the assertion.
+- **Leaving orphaned code**: If refactoring changes an interface, update ALL callers. If deleting a function, remove ALL imports of that function. Use search to verify zero remaining references.

package/plugin/skills/index-repo/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: index-repo
+description: Register and index a repo with Forge for intelligent code search, knowledge tracking, and graph analysis.
+version: 0.1.0
+---
+
+# /index-repo — Register & Index a Repository
+
+One-shot onboarding: register a repository with Forge and index it for intelligent code search, knowledge tracking, and graph analysis.
+
+## Behavior
+
+### Quick Setup (default)
+
+1. Check if `.forge/manifest.yaml` exists. If not, run `mcp__dk-forge__init` to create it.
+2. Run `mcp__dk-forge__register` to register the repo with the Forge server.
+3. Run `mcp__dk-forge__index_repo` to index the codebase (chunks code, generates embeddings, builds graph).
+
+```
+/index-repo
+```
+
+### With Options
+
+```
+/index-repo name:my-project stack:nestjs,typescript
+/index-repo force    (re-index even if already indexed)
+```
+
+### Status Check
+
+To check current index status: call `mcp__dk-forge__get_index_status`.
+
+```
+/index-repo status
+```
+
+## Init Parameters
+
+When initializing a new repo, infer these from the codebase:
+- **name**: From `package.json` name, directory name, or user input.
+- **stack**: Detect from package.json dependencies, file extensions, config files (e.g., `tsconfig.json` → typescript, `nest-cli.json` → nestjs).
+- **sharing**: Default `private`. Set `team` or `public` if the user requests it.
+
+## What Indexing Provides
+
+After indexing, the repo gains access to:
+- **`/search`** — 5-signal ranked code search (vector + graph + recency + hotspot + observations).
+- **`/impact`** — call graph traversal for dependency analysis.
+- **`/history`** — semantic git commit search and hotspot analysis.
+- **`/gotchas`** — known pitfalls and patterns from past pipeline runs.
+
+## Re-Indexing
+
+Run with `force: true` to re-index after significant codebase changes. The indexer is incremental but a force re-index ensures fresh embeddings.

package/plugin/skills/interviewing/SKILL.md

@@ -0,0 +1,225 @@
+---
+name: interviewing
+description: This skill should be used when conducting structured interviews with users for vision capture, requirements elicitation, design discovery, or architecture confirmation. Used by the strategist, product-manager, designer, and architect agents.
+user-invocable: false
+---
+
+# Interviewing Skill
+
+## Purpose
+
+Provide a disciplined, structured methodology for conducting user interviews within the Forge agent system. Apply this skill whenever an agent must gather information from the user -- whether for vision capture, requirements elicitation, design discovery, or architecture confirmation. The methodology ensures interviews are focused, efficient, and produce actionable, documented outcomes.
+
+---
+
+## Cardinal Rule: One Question at a Time
+
+Never present multiple questions in a single message. Every message to the user must contain exactly ONE question or decision point. This is non-negotiable.
+
+**Why**: Multiple questions cause the user to skim, answer partially, skip the hardest question, or give shallow answers to all. One question at a time forces depth, reduces cognitive load, and produces higher-quality signal.
+
+**The only exception**: When presenting a recap for confirmation, multiple items may appear in a single message because the user is reviewing, not generating answers.
+
+---
+
+## Question Format: Multi-Choice Over Open-Ended
+
+Prefer multi-choice questions over open-ended questions whenever the answer space is bounded. Multi-choice options reduce the user's cognitive load from "generate an answer" to "evaluate and select."
+
+### How to Structure Options
+
+- Present 2-5 concrete options, each with a brief description of what it means and its implications.
+- Include a description label for each option, not just bare keywords. "A) Monorepo -- all services in one repository, shared tooling, atomic commits across services" is better than "A) Monorepo."
+- Always include a final option for "None of these / something else" to avoid forcing the user into a false choice.
+- When one option is clearly recommended, mark it explicitly: "(recommended)" or "(default if you have no preference)."
+- When options have trade-offs, present a brief pro/con for each rather than burying the trade-off.
+
+### When Open-Ended Is Appropriate
+
+Use open-ended questions when:
+- The answer space is truly unbounded (e.g., "What problem are you trying to solve?").
+- The user's framing matters more than specific details (e.g., "How do you think about this feature's priority?").
+- Prior answers have not yet narrowed the space enough for options.
+
+Even with open-ended questions, provide context or a framing sentence to anchor the user's thinking: "You mentioned this is for internal teams. When you say 'internal,' are you thinking of engineering only, or all departments?"
+
+---
+
+## Interview Phases
+
+Every interview follows four phases in order. Do not skip phases, but adapt the depth of each phase based on how much is already known.
+
+### Phase 1: Discovery
+
+**Goal**: Understand the broad landscape -- the problem, the context, the stakeholders, and the user's mental model.
+
+- Start with the highest-level question: what is being built, for whom, and why.
+- Ask about prior art: has this been attempted before? Are there existing systems, processes, or workarounds?
+- Identify stakeholders: who benefits, who is affected, who has opinions.
+- Surface constraints early: timeline, budget, technology mandates, team capacity.
+- Do not dive into specifics yet. Resist the temptation to explore technical details during discovery.
+
+**Typical question count**: 4-8 questions.
+
+### Phase 2: Clarification
+
+**Goal**: Drill into the specifics surfaced during discovery. Turn vague statements into concrete, actionable requirements.
+
+- For each discovery answer that was broad or ambiguous, ask a follow-up that narrows it to something implementable.
+- Probe for edge cases: "You said users can upload files. What happens if the file is 500MB? What about unsupported formats?"
+- Probe for priorities: "You listed five features. If you could only ship two this iteration, which two?"
+- Probe for implicit assumptions: "You said 'fast.' What does fast mean to you -- sub-second page loads? Real-time updates? Same-day processing?"
+- Use context framing before each question: "Based on what you said about X, I want to clarify Y."
+
+**Typical question count**: 5-12 questions, depending on complexity.
+
+### Phase 3: Confirmation
+
+**Goal**: Verify understanding by presenting a structured summary and asking the user to confirm, correct, or amend.
+
+- Present a decision recap (see "Decision Recaps" section below) that summarizes all key findings from the interview.
+- Walk through each major point and ask: "Does this accurately capture your intent?"
+- For any corrections, ask one follow-up question to clarify, then update the recap.
+- Do not proceed to documentation until the user explicitly confirms the recap.
+
+**Typical question count**: 1-3 questions (recap + corrections).
+
+### Phase 4: Documentation
+
+**Goal**: Write all confirmed findings to the appropriate plan document.
+
+- Write findings to the plan document specified by the invoking agent (e.g., `vision.md`, `requirements.md`, `xd-plan.md`, `architecture.md`).
+- Use the document structure specified by the invoking agent.
+- Include a "Decision Log" entry for every decision made during the interview, with date, decision, rationale, and who decided.
+- Surface any open questions that the interview did not resolve -- these go into an "Open Questions" section and may need to be revisited.
+
+---
+
+## Progressive Depth
+
+Start every interview at the broadest level and narrow progressively based on the user's answers. Never jump to detail before establishing context.
+
+**The depth rule**: each question should be one level deeper than the previous question within its topic. If the user answered "We need user authentication," the next question within that topic should be about authentication specifically (e.g., "What identity providers do you need to support?"), not about database schema for auth tokens.
+
+**Cross-topic transitions**: When moving to a new topic, signal the transition explicitly: "That covers the authentication requirements. Now, let me ask about data storage."
+
+---
+
+## Context Framing
+
+Before every question (after the first), provide a brief context sentence that connects the question to what the user has already said. This serves three purposes:
+
+1. **Demonstrates active listening**: The user sees that their previous answers were heard and integrated.
+2. **Provides momentum**: The interview feels like a conversation building toward a goal, not a disconnected interrogation.
+3. **Catches misunderstandings early**: If the framing is wrong, the user will correct it before answering the new question.
+
+**Pattern**: "Based on [what you said about X], I want to explore [Y]. [Question]?"
+
+**Example**: "Based on your requirement for real-time collaboration, I want to understand the concurrency model. When two users edit the same document simultaneously, should their changes merge automatically, or should one user's changes take priority?"
+
+---
+
+## Decision Recaps
+
+At the end of each interview round (and at the end of the full interview), present a structured recap of all decisions and findings. The recap format must be:
+
+```
+---
+
+## Interview Recap
+
+> Round {N} Summary
+
+### Decisions Confirmed
+- **{Topic}**: {Decision} -- {Brief rationale}
+- **{Topic}**: {Decision} -- {Brief rationale}
+
+### Open Questions (Deferred)
+- {Question}: {Why it is deferred, when it should be resolved}
+
+### Scope Boundaries
+- **In Scope**: {List}
+- **Out of Scope**: {List}
+
+### Next Steps
+- {What happens next based on these decisions}
+
+---
+```
+
+Present the recap using the **terminal-presentation** skill for clear formatting. Ask the user to confirm: "Does this accurately capture what we discussed? Anything to correct or add?"
+
+---
+
+## Handling "I Don't Know" Answers
+
+When the user responds with "I don't know," "not sure," "whatever you think," or similar deflections:
+
+1. **Do not skip the topic.** An unresolved decision becomes an implicit decision that nobody owns.
+2. **Offer a default with reasoning.** "If you have no strong preference, the standard approach for this is X because Y. Shall I go with that?"
+3. **Label the default clearly in documentation.** Any decision made by default (rather than explicit user choice) must be marked in the decision log: "Decision: X (default -- user deferred to agent recommendation). Rationale: Y."
+4. **Set a review trigger.** If the default has significant downstream impact, note it as a review item: "This default should be revisited before production deployment."
+
+Never accept "I don't know" and move on without documenting what was decided by default.
+
+---
+
+## Handling Scope Creep During Interviews
+
+When the user introduces a topic or requirement that is outside the scope of the current interview:
+
+1. **Acknowledge it immediately.** "That is an interesting point about X."
+2. **Capture it visibly.** "I am noting that down as a potential future consideration."
+3. **Do not explore it.** Do not ask follow-up questions about the out-of-scope item. Do not let it redirect the interview.
+4. **Redirect back to scope.** "For this interview, let me stay focused on Y. We can circle back to X in a future session."
+5. **Document it.** Add the out-of-scope item to the "Deferred / Out of Scope" section of the plan document with a note about when it might be revisited.
+
+The goal is to honor the user's idea without letting it hijack the interview's focus.
+
+---
+
+## Adaptive Depth: When to Probe vs. When to Accept
+
+Not every answer requires deep follow-up. Use these heuristics to decide:
+
+### Probe Deeper When:
+- The answer is ambiguous or could be interpreted multiple ways.
+- The answer has significant architectural or cost implications that the user may not have considered.
+- The answer contradicts a previous answer or an established pattern.
+- The answer uses vague quantifiers ("a lot," "sometimes," "most users") that need grounding.
+- The topic is a known risk area (security, data migration, performance, authorization).
+
+### Accept and Move On When:
+- The answer is concrete, specific, and internally consistent.
+- The answer aligns with established project patterns or prior decisions.
+- The answer covers a low-risk area where the default is well-understood.
+- The user signals impatience with a topic ("Yeah, the standard way is fine").
+- Further depth would not change the implementation approach.
+
+### Explicit Depth Signals from the User:
+- "Plow through" / "just make it work" / "default is fine" = Accept the answer, apply sensible defaults, document them, and move on. Reduce remaining question count.
+- "Let me think about that" / "good question" = The user is engaged. Allow a moment, then offer options to help structure their thinking.
+- "That is out of scope" / "not this iteration" = Capture it in the deferred section and move on immediately.
+
+---
+
+## Output Requirements
+
+Every interview must produce written output. Never conduct an interview that ends with only a verbal summary.
+
+1. **Primary output**: Write all findings to the plan document specified by the invoking agent. Use the document structure that agent expects.
+2. **Decision log**: Every decision made during the interview gets a log entry with date, decision, rationale, and decider (user or agent-default).
+3. **Open questions**: Any unresolved topics go into an "Open Questions" section with notes on when and how they should be resolved.
+4. **Deferred items**: Any scope creep items captured during the interview go into a "Deferred / Out of Scope" section.
+
+---
+
+## Anti-Patterns to Avoid
+
+- **Question dumping**: Never present more than one question per message. This is the most common and most damaging violation.
+- **Leading questions**: Do not embed the "right" answer in the question. "Don't you think we should use WebSockets?" is a leading question. "What communication pattern fits best here: polling, SSE, or WebSockets?" is a neutral question.
+- **Jargon without context**: If using a technical term, define it briefly unless the user has already demonstrated familiarity. "Should we use CQRS -- that is, separating the read and write models -- for this service?"
+- **Ignoring prior answers**: Never ask a question whose answer was already given in a previous response. Re-read the full interview context before each question.
+- **Interviewing past the point of value**: If the user has given enough information to proceed, stop interviewing. Do not ask questions for the sake of completeness when the answers will not change the plan.
+- **Skipping the recap**: Always present a confirmation recap. Never go straight from questions to documentation without user confirmation.
+- **Treating "I don't know" as "skip"**: Always offer a default and document it.