From bff0bc7ad13826e343178427c8b28e954e31526b Mon Sep 17 00:00:00 2001 From: Henrik Date: Fri, 3 Oct 2025 12:42:37 +0200 Subject: [PATCH 01/10] Improve CLAUDE.md and remove WARP.md --- CLAUDE.md | 57 ++++++++++++++- WARP.md | 203 ------------------------------------------------------ 2 files changed, 56 insertions(+), 204 deletions(-) delete mode 100644 WARP.md diff --git a/CLAUDE.md b/CLAUDE.md index f4b3f9c..bf3c5fa 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -66,11 +66,24 @@ The builder binary expects a YAML configuration file as its first argument: ## Key Design Patterns - **Command Pattern**: Each build operation is implemented as a separate command struct with its own module -- **Configuration-driven**: The tool is entirely driven by TOML configuration files +- **Configuration-driven**: The tool is entirely driven by YAML configuration files - **Workspace architecture**: Modular design with separate crates for different responsibilities - **Error handling**: Uses `anyhow` for error handling throughout - **File system abstraction**: Uses `camino-fs` for UTF-8 path handling +## Command Types + +The `Cmd` enum supports these build operations: + +- **Sass** - SCSS compilation with dart-sass or built-in grass compiler +- **Wasm** - Rust to WebAssembly compilation with wasm-bindgen and optimization +- **Uniffi** - Swift/Kotlin bindings generation from UniFFI .udl files +- **SwiftPackage** - Swift package creation +- **FontForge** - Font processing (SFD to WOFF2/OTF) +- **Assemble** - Asset scanning and Rust code generation +- **Localized** - Internationalized content handling +- **Copy** - Simple file copying with filtering + ## Working with Command Modules When adding new commands or modifying existing ones: @@ -81,3 +94,45 @@ When adding new commands or modifying existing ones: 5. Create a corresponding crate in `crates/` for the actual implementation The builder uses YAML serialization via serde for configuration files, providing human-readable and standard format handling with automatic field serialization. + +## Asset Code Generation + +Builder can generate Rust code for type-safe asset access with two data providers: + +- **DataProvider::FileSystem** - Loads assets from disk at runtime +- **DataProvider::Embed** - Embeds assets in binary using rust-embed + +Usage in build scripts: +```rust +.add_output(Output::new("dist") + .asset_code_gen("src/assets.rs", DataProvider::Embed)) +``` + +Runtime configuration (FileSystem provider only): +```rust +use builder_assets::set_asset_base_path; +set_asset_base_path("/path/to/assets"); +``` + +See `crates/examples/` for a complete working example. + +## WASM Debug Symbols + +Four debug symbol modes for WASM builds: + +```rust +WasmProcessingCmd::new("package", Profile::Release) + .debug_symbols(DebugSymbolsMode::Strip) // Remove (default) + .debug_symbols(DebugSymbolsMode::Keep) // Keep in main file + .debug_symbols(DebugSymbolsMode::WriteAdjacent) // Separate .debug.wasm + .debug_symbols(DebugSymbolsMode::WriteTo("path")) // Custom path +``` + +## Key Implementation Notes + +- Uses `camino-fs` for UTF-8 path handling throughout +- Error handling with `anyhow` +- YAML serialization via `serde` for configuration files +- Workspace uses Rust 2024 edition +- All command modules implement caching based on content hashes +- Asset code generation supports content negotiation and compression diff --git a/WARP.md b/WARP.md deleted file mode 100644 index b3a0079..0000000 --- a/WARP.md +++ /dev/null @@ -1,203 +0,0 @@ -# WARP.md - -This file provides guidance to WARP (warp.dev) when working with code in this repository. - -## Quickstart - -Build and test the project: -```bash -# Build all crates -cargo build --workspace - -# Build release binary -cargo build --release -p builder - -# Run all tests (requires external dependencies - see below) -cargo test --workspace - -# Alternative: use nextest for better test output -cargo nextest run - -# Check code without building -cargo check --workspace -``` - -Run the builder tool: -```bash -# Show version -./target/release/builder -V - -# Run with configuration file -./target/release/builder path/to/builder.json - -# Example using the examples crate -cd crates/examples -cargo run # This builds and runs the example -``` - -## Architecture Overview - -Builder is a Rust workspace containing a command-line tool for building web assets, WASM, and mobile libraries. The architecture is: - -1. **Configuration Phase**: Rust build scripts use the `BuilderCmd` struct (from `builder-command` crate) with fluent builder pattern to configure build commands, then generate a `builder.json` file -2. **Execution Phase**: The `builder` CLI binary reads the JSON configuration and executes each build command in sequence - -Key files: -- `crates/command/src/lib.rs` - Contains `BuilderCmd` fluent API and `Cmd` enum with all command types -- `crates/builder/src/main.rs` - CLI entry point that dispatches to command modules -- Individual command implementations in feature crates: `sass`, `wasm`, `uniffi`, `fontforge`, etc. - -## Command Types - -The `Cmd` enum in `crates/command/src/lib.rs` supports these build operations: - -- **Sass** - SCSS compilation with dart-sass or built-in grass compiler -- **Wasm** - Rust to WebAssembly compilation with wasm-bindgen and optimization -- **Uniffi** - Swift/Kotlin bindings generation from UniFFI .udl files -- **SwiftPackage** - Swift package creation -- **FontForge** - Font processing (SFD to WOFF2/OTF) -- **Assemble** - Asset scanning and Rust code generation -- **Localized** - Internationalized content handling -- **Copy** - Simple file copying with filtering - -## JSON Configuration Format - -Build scripts create configuration using the fluent API: - -```rust -use builder_command::{BuilderCmd, SassCmd, WasmProcessingCmd, Output, Profile, DataProvider}; - -BuilderCmd::new() - .add_sass(SassCmd::new("styles/main.scss") - .add_output(Output::new("dist") - .asset_code_gen("src/assets.rs", DataProvider::Embed))) - .add_wasm(WasmProcessingCmd::new("my-wasm-package", Profile::Release) - .add_output(Output::new("dist/wasm"))) - .run(); // Generates builder.json and executes -``` - -This generates a JSON configuration that the CLI tool processes. - -## Workspace Structure - -Key crates and their roles: - -- **`builder`** - CLI binary entry point (`crates/builder/src/main.rs`) -- **`command`** - Command definitions and fluent API (`crates/command/src/lib.rs`) -- **`common`** - Shared utilities, logging, and file system operations -- **`assets`** - Asset management library for generated code -- Feature-specific crates: - - **`sass`** - SCSS compilation logic - - **`wasm`** - WebAssembly build pipeline with debug symbol handling - - **`uniffi`** - UniFFI bindings with caching - - **`fontforge`** - Font processing integration - - **`assemble`** - Asset directory scanning and code generation - - **`localized`** - Multi-language asset handling - - **`copy`** - File copying operations - - **`swift_package`** - Swift package generation -- **`examples`** - Working example showing multi-provider asset generation - -## External Dependencies - -For full testing, install these external tools: - -```bash -# WASM target for Rust -rustup target add wasm32-unknown-unknown - -# FontForge for font processing -# macOS: -brew install fontforge -# Linux: -sudo apt-get install fontforge - -# Dart Sass for advanced SCSS features (optional - has fallback) -curl -L https://github.com/sass/dart-sass/releases/download/1.77.8/dart-sass-1.77.8-linux-x64.tar.gz | tar xz -C /usr/local/bin --strip-components=1 dart-sass -``` - -No database or external services are required - all dependencies are build tools. - -## Testing - -Different test categories: - -```bash -# Unit tests only (no external deps needed) -cargo test --lib --workspace - -# All tests including integration tests (requires external tools) -cargo test --workspace - -# Using nextest for better output -cargo nextest run --workspace - -# Test a specific command implementation -cargo test -p builder-sass - -# Run examples to test end-to-end functionality -cd crates/examples && cargo run -``` - -## Asset Code Generation - -Builder can generate Rust code for type-safe asset access: - -**Two data providers:** -- `DataProvider::FileSystem` - Loads assets from disk at runtime -- `DataProvider::Embed` - Embeds assets in binary using rust-embed - -**Usage in build scripts:** -```rust -.add_output(Output::new("dist") - .asset_code_gen("src/assets.rs", DataProvider::Embed)) -``` - -**Runtime configuration (FileSystem provider only):** -```rust -use builder_assets::set_asset_base_path; -set_asset_base_path("/path/to/assets"); -``` - -See `crates/examples/` for a complete working example with both providers. - -## WASM Debug Symbols - -Four debug symbol modes for WASM builds: - -```rust -WasmProcessingCmd::new("package", Profile::Release) - .debug_symbols(DebugSymbolsMode::Strip) // Remove (default) - .debug_symbols(DebugSymbolsMode::Keep) // Keep in main file - .debug_symbols(DebugSymbolsMode::WriteAdjacent) // Separate .debug.wasm - .debug_symbols(DebugSymbolsMode::WriteTo("path")) // Custom path -``` - -## Release Process - -This project uses `cargo-dist` for releases: - -1. Update version in root `Cargo.toml` (workspace.package.version) -2. Create and push annotated tag: - ```bash - git tag v0.1.28 -m "Version 0.1.28: description" - git push --tags - ``` -3. GitHub Actions automatically builds and publishes binaries -4. Install via: `cargo binstall builder` - -## Key Implementation Notes - -- Uses `camino-fs` for UTF-8 path handling throughout -- Error handling with `anyhow` -- JSON serialization via `serde` for configuration files -- Workspace uses Rust 2024 edition -- All command modules implement caching based on content hashes -- Asset code generation supports content negotiation and compression - -## Sources of Truth - -- **README.md** - User-facing documentation and feature overview -- **CLAUDE.md** - Architecture details and development workflow -- **Cargo.toml** - Workspace configuration and dependencies -- **.github/workflows/rust.yml** - CI setup and external tool requirements -- **crates/examples/** - Working end-to-end example \ No newline at end of file From 9f28d2780aef767aa8b196deb189253a60a97d09 Mon Sep 17 00:00:00 2001 From: Henrik Date: Fri, 3 Oct 2025 12:47:01 +0200 Subject: [PATCH 02/10] Update CLAUDE --- CLAUDE.md | 38 +++++++++++++++++++++++++++++--------- 1 file changed, 29 insertions(+), 9 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index bf3c5fa..a03e5b6 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -18,6 +18,8 @@ This is a Rust workspace containing a command-line tool for building web assets, - `copy/` - File copying operations - `swift_package/` - Swift package generation - **Common utilities**: `crates/common/` - Shared utilities including file system operations and logging +- **Runtime library**: `crates/assets/` - Runtime support for generated asset code with content negotiation +- **Examples**: `crates/examples/` - Working example demonstrating multi-provider asset generation (excluded from workspace, requires builder binary) The tool works by: 1. Reading a YAML configuration file (builder.yaml format) @@ -29,6 +31,7 @@ The tool works by: ### Building and Testing ```bash # Clean build workflow (build builder binary first, then everything else) +# This is required because build.rs files in the workspace use the builder binary cargo build -p builder && cargo build # Or for tests @@ -45,12 +48,18 @@ cargo check # Build specific crate cargo build -p builder + +# Run the examples crate (excluded from workspace, requires builder binary) +cd crates/examples && cargo run ``` ### External Dependencies Required for Testing -- **FontForge**: `sudo apt-get install fontforge` (Linux) or equivalent -- **Sass**: Download dart-sass from GitHub releases +- **FontForge**: + - Linux: `sudo apt-get install fontforge` + - macOS: `brew install fontforge` +- **Sass**: Download dart-sass from GitHub releases (optional - has grass fallback) - **WASM target**: `rustup target add wasm32-unknown-unknown` +- **nextest** (optional): `cargo install cargo-nextest` for better test output ### Running the Tool The builder binary expects a YAML configuration file as its first argument: @@ -59,9 +68,13 @@ The builder binary expects a YAML configuration file as its first argument: ``` ### Release Process -1. Update version in `Cargo.toml` -2. Create and push git tag: `git tag v0.1.20 -m"Version 0.1.20: description"` -3. CI automatically builds and releases via cargo-dist +1. Update version in root `Cargo.toml` (workspace.package.version) +2. Create and push annotated git tag: `git tag v0.1.X -m "Version 0.1.X: description"` +3. Push tag: `git push --tags` +4. CI automatically builds and releases via cargo-dist +5. Users can install via: `cargo binstall builder` + +Current version: 0.1.28 ## Key Design Patterns @@ -102,10 +115,17 @@ Builder can generate Rust code for type-safe asset access with two data provider - **DataProvider::FileSystem** - Loads assets from disk at runtime - **DataProvider::Embed** - Embeds assets in binary using rust-embed -Usage in build scripts: +Usage in build.rs: ```rust -.add_output(Output::new("dist") - .asset_code_gen("src/assets.rs", DataProvider::Embed)) +use builder_command::{BuilderCmd, CopyCmd, DataProvider, Output}; + +BuilderCmd::new() + .add_copy(CopyCmd::new("assets") + .recursive(true) + .file_extensions(["css", "js", "png"]) + .add_output(Output::new("dist") + .asset_code_gen("src/assets.rs", DataProvider::Embed))) + .exec("path/to/builder"); // Execute using builder binary ``` Runtime configuration (FileSystem provider only): @@ -114,7 +134,7 @@ use builder_assets::set_asset_base_path; set_asset_base_path("/path/to/assets"); ``` -See `crates/examples/` for a complete working example. +The generated code uses the `builder-assets` crate for runtime support. See `crates/examples/build.rs` for a complete working example with both providers. ## WASM Debug Symbols From cf540d71034f24701d4496ea20a6e35b9d461b7e Mon Sep 17 00:00:00 2001 From: Henrik Date: Fri, 3 Oct 2025 12:52:02 +0200 Subject: [PATCH 03/10] Remove AssembleCmd and add specify --- .claude/commands/analyze.md | 101 +++ .claude/commands/clarify.md | 158 ++++ .claude/commands/constitution.md | 73 ++ .claude/commands/implement.md | 56 ++ .claude/commands/plan.md | 43 ++ .claude/commands/specify.md | 21 + .claude/commands/tasks.md | 62 ++ .specify/memory/constitution.md | 183 +++++ .specify/scripts/bash/check-prerequisites.sh | 166 ++++ .specify/scripts/bash/common.sh | 113 +++ .specify/scripts/bash/create-new-feature.sh | 97 +++ .specify/scripts/bash/setup-plan.sh | 60 ++ .specify/scripts/bash/update-agent-context.sh | 728 ++++++++++++++++++ .specify/templates/agent-file-template.md | 23 + .specify/templates/plan-template.md | 263 +++++++ .specify/templates/spec-template.md | 116 +++ .specify/templates/tasks-template.md | 127 +++ CLAUDE.md | 4 +- Cargo.lock | 13 - crates/assemble/Cargo.toml | 17 - crates/assemble/src/asset_ext.rs | 39 - crates/assemble/src/asset_incl.rs | 18 - crates/assemble/src/generator.rs | 94 --- crates/assemble/src/lib.rs | 81 -- crates/assets/README.md | 2 +- crates/assets/src/lib.rs | 2 +- crates/builder/Cargo.toml | 1 - crates/builder/src/main.rs | 1 - crates/command/src/assemble.rs | 63 -- crates/command/src/lib.rs | 10 - 30 files changed, 2393 insertions(+), 342 deletions(-) create mode 100644 .claude/commands/analyze.md create mode 100644 .claude/commands/clarify.md create mode 100644 .claude/commands/constitution.md create mode 100644 .claude/commands/implement.md create mode 100644 .claude/commands/plan.md create mode 100644 .claude/commands/specify.md create mode 100644 .claude/commands/tasks.md create mode 100644 .specify/memory/constitution.md create mode 100755 .specify/scripts/bash/check-prerequisites.sh create mode 100755 .specify/scripts/bash/common.sh create mode 100755 .specify/scripts/bash/create-new-feature.sh create mode 100755 .specify/scripts/bash/setup-plan.sh create mode 100755 .specify/scripts/bash/update-agent-context.sh create mode 100644 .specify/templates/agent-file-template.md create mode 100644 .specify/templates/plan-template.md create mode 100644 .specify/templates/spec-template.md create mode 100644 .specify/templates/tasks-template.md delete mode 100644 crates/assemble/Cargo.toml delete mode 100644 crates/assemble/src/asset_ext.rs delete mode 100644 crates/assemble/src/asset_incl.rs delete mode 100644 crates/assemble/src/generator.rs delete mode 100644 crates/assemble/src/lib.rs delete mode 100644 crates/command/src/assemble.rs diff --git a/.claude/commands/analyze.md b/.claude/commands/analyze.md new file mode 100644 index 0000000..f4c1a7b --- /dev/null +++ b/.claude/commands/analyze.md @@ -0,0 +1,101 @@ +--- +description: Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation. +--- + +The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty). + +User input: + +$ARGUMENTS + +Goal: Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/tasks` has successfully produced a complete `tasks.md`. + +STRICTLY READ-ONLY: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually). + +Constitution Authority: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/analyze`. + +Execution steps: + +1. Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths: + - SPEC = FEATURE_DIR/spec.md + - PLAN = FEATURE_DIR/plan.md + - TASKS = FEATURE_DIR/tasks.md + Abort with an error message if any required file is missing (instruct the user to run missing prerequisite command). + +2. Load artifacts: + - Parse spec.md sections: Overview/Context, Functional Requirements, Non-Functional Requirements, User Stories, Edge Cases (if present). + - Parse plan.md: Architecture/stack choices, Data Model references, Phases, Technical constraints. + - Parse tasks.md: Task IDs, descriptions, phase grouping, parallel markers [P], referenced file paths. + - Load constitution `.specify/memory/constitution.md` for principle validation. + +3. Build internal semantic models: + - Requirements inventory: Each functional + non-functional requirement with a stable key (derive slug based on imperative phrase; e.g., "User can upload file" -> `user-can-upload-file`). + - User story/action inventory. + - Task coverage mapping: Map each task to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases). + - Constitution rule set: Extract principle names and any MUST/SHOULD normative statements. + +4. Detection passes: + A. Duplication detection: + - Identify near-duplicate requirements. Mark lower-quality phrasing for consolidation. + B. Ambiguity detection: + - Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria. + - Flag unresolved placeholders (TODO, TKTK, ???, , etc.). + C. Underspecification: + - Requirements with verbs but missing object or measurable outcome. + - User stories missing acceptance criteria alignment. + - Tasks referencing files or components not defined in spec/plan. + D. Constitution alignment: + - Any requirement or plan element conflicting with a MUST principle. + - Missing mandated sections or quality gates from constitution. + E. Coverage gaps: + - Requirements with zero associated tasks. + - Tasks with no mapped requirement/story. + - Non-functional requirements not reflected in tasks (e.g., performance, security). + F. Inconsistency: + - Terminology drift (same concept named differently across files). + - Data entities referenced in plan but absent in spec (or vice versa). + - Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note). + - Conflicting requirements (e.g., one requires to use Next.js while other says to use Vue as the framework). + +5. Severity assignment heuristic: + - CRITICAL: Violates constitution MUST, missing core spec artifact, or requirement with zero coverage that blocks baseline functionality. + - HIGH: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion. + - MEDIUM: Terminology drift, missing non-functional task coverage, underspecified edge case. + - LOW: Style/wording improvements, minor redundancy not affecting execution order. + +6. Produce a Markdown report (no file writes) with sections: + + ### Specification Analysis Report + | ID | Category | Severity | Location(s) | Summary | Recommendation | + |----|----------|----------|-------------|---------|----------------| + | A1 | Duplication | HIGH | spec.md:L120-134 | Two similar requirements ... | Merge phrasing; keep clearer version | + (Add one row per finding; generate stable IDs prefixed by category initial.) + + Additional subsections: + - Coverage Summary Table: + | Requirement Key | Has Task? | Task IDs | Notes | + - Constitution Alignment Issues (if any) + - Unmapped Tasks (if any) + - Metrics: + * Total Requirements + * Total Tasks + * Coverage % (requirements with >=1 task) + * Ambiguity Count + * Duplication Count + * Critical Issues Count + +7. At end of report, output a concise Next Actions block: + - If CRITICAL issues exist: Recommend resolving before `/implement`. + - If only LOW/MEDIUM: User may proceed, but provide improvement suggestions. + - Provide explicit command suggestions: e.g., "Run /specify with refinement", "Run /plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'". + +8. Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.) + +Behavior rules: +- NEVER modify files. +- NEVER hallucinate missing sections—if absent, report them. +- KEEP findings deterministic: if rerun without changes, produce consistent IDs and counts. +- LIMIT total findings in the main table to 50; aggregate remainder in a summarized overflow note. +- If zero issues found, emit a success report with coverage statistics and proceed recommendation. + +Context: $ARGUMENTS diff --git a/.claude/commands/clarify.md b/.claude/commands/clarify.md new file mode 100644 index 0000000..26ff530 --- /dev/null +++ b/.claude/commands/clarify.md @@ -0,0 +1,158 @@ +--- +description: Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec. +--- + +The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty). + +User input: + +$ARGUMENTS + +Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file. + +Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases. + +Execution steps: + +1. Run `.specify/scripts/bash/check-prerequisites.sh --json --paths-only` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields: + - `FEATURE_DIR` + - `FEATURE_SPEC` + - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.) + - If JSON parsing fails, abort and instruct user to re-run `/specify` or verify feature branch environment. + +2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear / Partial / Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked). + + Functional Scope & Behavior: + - Core user goals & success criteria + - Explicit out-of-scope declarations + - User roles / personas differentiation + + Domain & Data Model: + - Entities, attributes, relationships + - Identity & uniqueness rules + - Lifecycle/state transitions + - Data volume / scale assumptions + + Interaction & UX Flow: + - Critical user journeys / sequences + - Error/empty/loading states + - Accessibility or localization notes + + Non-Functional Quality Attributes: + - Performance (latency, throughput targets) + - Scalability (horizontal/vertical, limits) + - Reliability & availability (uptime, recovery expectations) + - Observability (logging, metrics, tracing signals) + - Security & privacy (authN/Z, data protection, threat assumptions) + - Compliance / regulatory constraints (if any) + + Integration & External Dependencies: + - External services/APIs and failure modes + - Data import/export formats + - Protocol/versioning assumptions + + Edge Cases & Failure Handling: + - Negative scenarios + - Rate limiting / throttling + - Conflict resolution (e.g., concurrent edits) + + Constraints & Tradeoffs: + - Technical constraints (language, storage, hosting) + - Explicit tradeoffs or rejected alternatives + + Terminology & Consistency: + - Canonical glossary terms + - Avoided synonyms / deprecated terms + + Completion Signals: + - Acceptance criteria testability + - Measurable Definition of Done style indicators + + Misc / Placeholders: + - TODO markers / unresolved decisions + - Ambiguous adjectives ("robust", "intuitive") lacking quantification + + For each category with Partial or Missing status, add a candidate question opportunity unless: + - Clarification would not materially change implementation or validation strategy + - Information is better deferred to planning phase (note internally) + +3. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints: + - Maximum of 5 total questions across the whole session. + - Each question must be answerable with EITHER: + * A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR + * A one-word / short‑phrase answer (explicitly constrain: "Answer in <=5 words"). + - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation. + - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved. + - Exclude questions already answered, trivial stylistic preferences, or plan-level execution details (unless blocking correctness). + - Favor clarifications that reduce downstream rework risk or prevent misaligned acceptance tests. + - If more than 5 categories remain unresolved, select the top 5 by (Impact * Uncertainty) heuristic. + +4. Sequential questioning loop (interactive): + - Present EXACTLY ONE question at a time. + - For multiple‑choice questions render options as a Markdown table: + + | Option | Description | + |--------|-------------| + | A |