@garygentry/feature-forge 0.2.14 → 0.3.1

package/adapters/pi/skills/forge-guide/references/stacks/rust.md

@@ -0,0 +1,170 @@
+# Rust Stack Profile
+
+Stack-specific guidance for Rust projects (stable channel).
+
+## Stack Identity
+
+- **Language**: Rust (stable channel, edition 2021 or later)
+- **Build system**: Cargo (`cargo build`, `cargo test`, `cargo run`)
+- **Package registry**: crates.io (dependencies declared in `Cargo.toml`)
+- **Philosophy**: Zero-cost abstractions, ownership model for memory safety, fearless concurrency
+
+## Discovery Checklist
+
+When examining a Rust project, check for:
+
+- **Project manifest**: `Cargo.toml` (package metadata, dependencies, features, workspace config)
+- **Dependency lock**: `Cargo.lock` (exact dependency versions for reproducible builds)
+- **Library entry**: `src/lib.rs` (library crate root)
+- **Binary entry**: `src/main.rs` (binary crate root), or `src/bin/` for multiple binaries
+- **Build script**: `build.rs` (compile-time code generation, native library linking)
+- **Cargo config**: `.cargo/config.toml` (target-specific settings, linker config, aliases)
+- **Workspace**: `[workspace]` table in root `Cargo.toml` with `members` list
+- **Framework**: Check `Cargo.toml` dependencies for actix-web, axum, rocket (web), clap (CLI), tokio (async)
+- **Async runtime**: tokio, async-std, smol
+- **Serialization**: serde, serde_json, serde_yaml
+
+## Archetype Conventions
+
+### 00-core-definitions.md (Rust)
+
+- **Structs**: Use `struct` types with derive macros (`#[derive(Debug, Clone, Serialize, Deserialize)]`). Document every public field with `///` doc comments.
+- **Enums**: Use for sum types / discriminated unions. Each variant documents its purpose. Exhaustive `match` for control flow.
+- **Traits**: Define shared behavior contracts. Keep focused (single responsibility). Use associated types for output types, generics for input types.
+- **Error types**: `thiserror::Error` for library errors (typed, specific), `anyhow::Error` for application errors (erased, convenient). Define `type Result<T> = std::result::Result<T, MyError>` aliases per module.
+- **Type aliases**: Use `type` for complex generic instantiations (e.g., `type DbPool = Pool<Postgres>`)
+- **Newtypes**: Single-field tuple structs for type safety (e.g., `struct UserId(Uuid)`)
+- **Constants**: `const` for compile-time values, `static` for global state (rarely needed), `lazy_static!` or `std::sync::LazyLock` for runtime-initialized globals
+
+### 01-architecture-layout.md (Rust)
+
+- **Single crate structure**:
+  - `src/lib.rs` — library root, declares modules with `mod` statements
+  - `src/main.rs` — binary entry point, imports from library crate
+  - `src/<module>.rs` or `src/<module>/mod.rs` — submodules
+  - `tests/` — integration tests (each file is a separate crate)
+  - `examples/` — runnable examples (`cargo run --example name`)
+  - `benches/` — benchmarks (`cargo bench`)
+- **Cargo workspace** (multi-crate):
+  - Root `Cargo.toml` with `[workspace]` and `members = ["crates/*"]`
+  - Shared dependencies via `[workspace.dependencies]` with `{ workspace = true }` in member crates
+  - Internal crate references as path dependencies
+- **Cargo.toml**: `[package]` (name, version, edition), `[dependencies]`, `[dev-dependencies]`, `[build-dependencies]`, `[features]` for conditional compilation
+- **Module visibility**: `pub`, `pub(crate)`, `pub(super)` for fine-grained access control. Re-exports via `pub use` in parent modules.
+
+### NN-testing-strategy.md (Rust)
+
+- **Framework**: Built-in `#[test]` attribute (no external framework required)
+- **Unit tests**: `#[cfg(test)] mod tests { ... }` at bottom of each source file (white-box, access to private items)
+- **Integration tests**: `tests/` directory, each `.rs` file is a separate test crate (black-box, only public API)
+- **Test assertions**: `assert!`, `assert_eq!`, `assert_ne!` macros; custom messages as format string arguments
+- **Doc tests**: Code blocks in `///` doc comments run as tests with `cargo test`
+- **Examples**: `examples/` directory, verified to compile with `cargo test`, runnable with `cargo run --example`
+- **Test fixtures**: Builder pattern structs, helper functions in `tests/common/mod.rs`
+- **Async tests**: `#[tokio::test]` attribute for async test functions
+- **Property testing**: `proptest` or `quickcheck` crates for generative testing
+- **Snapshot testing**: `insta` crate for snapshot/approval testing
+
+## Spec Quality Rules
+
+- All Rust code must be valid syntax with complete type annotations — not pseudocode
+- Follow Rust idioms:
+  - `Result<T, E>` for fallible operations — never panic for expected failures
+  - `Option<T>` for nullable/optional values — never use sentinel values
+  - Ownership and borrowing: specify whether a function takes ownership (`T`), borrows (`&T`), or mutably borrows (`&mut T`). Note when `Clone` is required.
+  - Lifetime annotations when the compiler cannot infer them — document why a lifetime relationship exists
+  - Derive macros for common traits (`Debug`, `Clone`, `PartialEq`, `Eq`, `Hash`, `Serialize`, `Deserialize`)
+  - `impl` blocks for methods — group inherent methods and trait implementations separately
+  - Pattern matching with `match` for control flow over enums and `Result`/`Option`
+  - `?` operator for error propagation — avoid manual `match` on `Result` when `?` suffices
+- Document every public item with `///` doc comments including `# Examples` sections for non-trivial APIs
+- Use `#[must_use]` on functions whose return values should not be ignored
+- Include complete `use` statements in all code examples
+
+## Verification Specifics
+
+- **Type checking**: `cargo check` (fast compile without codegen — catches all type errors)
+- **Linting**: `cargo clippy` (idiomatic Rust lints, catches common mistakes)
+- **Testing**: `cargo test` (unit tests, integration tests, doc tests, examples)
+- **Documentation**: `cargo doc --no-deps` (ensures documentation compiles, catches broken links)
+- **Formatting**: `cargo fmt --check` (ensures code matches `rustfmt` style)
+- **Unsafe audit**: `cargo geiger` (if security-sensitive — counts unsafe blocks)
+
+### Runtime Entrypoints & Bootstrap-Wiring Sites
+
+Used by `CHECK-I22` (a runtime-required bootstrap needs a **non-test** caller on one of these) and
+`CHECK-I23` (a heavy init wired into a **universal** bootstrap entry should move to a lazier site).
+
+- **Runtime entrypoints (a legitimate non-test call site):** `fn main()` in `main.rs` or a `[[bin]]`
+  target, an async runtime entry (`#[tokio::main]`), an HTTP handler registered on an axum/actix/warp
+  router, or a worker task spawned from `main` — not a `#[cfg(test)]` module or a `tests/` integration
+  file.
+- **Universal bootstrap entries (run on every startup — the `CHECK-I23` risk site):** a `lazy_static!`
+  / `once_cell::sync::Lazy` static that eagerly constructs heavy clients, a single `bootstrap`/`setup`
+  fn `main` calls before serving, or a `#[ctor]`-style pre-`main` initializer. A `Lazy` static is only
+  a risk when it is *forced* at startup rather than on first use.
+- **Heavy server-only import markers (what makes an init "heavy" for `CHECK-I23`):** DB pools
+  (`sqlx::Pool`, `diesel`, `deadpool`, `mongodb`), message/queue clients (`rdkafka`, `lapin`,
+  `redis`), telemetry SDKs (`opentelemetry`, `sentry`), or a broad internal service crate. Constructing
+  any of these eagerly at a universal entry is the CHECK-I23 pattern — recommend a `OnceCell`/`Lazy`
+  forced on **first use** by the handler that needs it, not at process start.
+
+## Testing
+
+- **Framework**: Built-in test harness (`#[test]`, `#[cfg(test)]`)
+- **Test command**: `cargo test` for all, `cargo test test_name` for specific, `cargo test --lib` for unit only
+- **Unit tests**: `#[cfg(test)] mod tests` at bottom of source files
+- **Integration tests**: `tests/` directory, each file is a separate crate
+- **Doc tests**: Code in `///` comments, verified by `cargo test --doc`
+- **Assertions**: `assert!`, `assert_eq!`, `assert_ne!` with optional format messages
+- **Async tests**: `#[tokio::test]` macro for async test functions
+- **Snapshot testing**: `insta` crate with `assert_snapshot!` / `assert_debug_snapshot!`
+- **Coverage**: `cargo llvm-cov` or `cargo tarpaulin`
+- **Benchmarks**: `criterion` crate or built-in `#[bench]` (nightly)
+
+## Common Frameworks
+
+| Category | Options |
+|----------|---------|
+| Web (async) | axum, actix-web, rocket, warp |
+| Serialization | serde, serde_json, serde_yaml, toml |
+| Async runtime | tokio, async-std, smol |
+| Database | sqlx, diesel, sea-orm |
+| Migrations | sqlx-cli, diesel-cli, refinery |
+| CLI | clap, argh, structopt (legacy) |
+| Observability | tracing, tracing-subscriber, metrics |
+| HTTP client | reqwest, hyper, ureq (blocking) |
+| Middleware | tower, tower-http, actix middleware |
+| Error handling | thiserror (library), anyhow (application), eyre |
+
+## Example: Project-Level Override
+
+Create `.feature-forge/stack-decisions.md` (legacy alias: `.claude/references/stack-decisions.md`) in your project root:
+
+```markdown
+# Stack Decisions
+
+## Runtime & Build
+- Rust stable (edition 2021)
+- Cargo workspace with crates/ directory
+
+## Backend
+- axum for HTTP framework
+- sqlx with PostgreSQL (compile-time query checking)
+- tokio as async runtime
+
+## Serialization & Validation
+- serde for serialization/deserialization
+- Custom validation via trait implementations
+
+## Testing
+- Built-in #[test] with assert macros
+- Integration tests in tests/ directory
+- insta for snapshot testing
+
+## Conventions
+- thiserror for library error types, anyhow in binary
+- tracing for structured logging
+- cargo clippy must pass with no warnings
+- All public APIs documented with /// and examples
+```

package/adapters/pi/skills/forge-guide/references/stacks/typescript.md

@@ -0,0 +1,134 @@
+# TypeScript Stack Profile
+
+Stack-specific guidance for TypeScript projects (Node.js/Bun, monorepo or single-package).
+
+## Stack Identity
+
+- **Language**: TypeScript
+- **Runtime**: Node.js or Bun (check `package.json` `engines` field and lock files)
+- **Package management**: npm, pnpm, yarn, or bun (check for respective lock files)
+- **Common monorepo tools**: Turborepo (`turbo.json`), Nx (`nx.json`), Lerna (`lerna.json`)
+
+## Discovery Checklist
+
+When examining a TypeScript project, check for:
+
+- **Runtime**: Bun or Node.js (check `package.json` for which)
+- **Package management**: Check for `bun.lockb`, `pnpm-lock.yaml`, `package-lock.json`, or `yarn.lock`
+- **Monorepo**: Check for `turbo.json` (Turborepo), `nx.json` (Nx), or `lerna.json` (Lerna)
+- **Framework**: Check existing packages for Hono, Express, Fastify, etc.
+- **Frontend**: Check for React, Vue, Svelte, etc.
+- **Routing**: Check for TanStack Router, React Router, Next.js, etc.
+- **Database**: Check for Drizzle, Prisma, TypeORM, etc.
+- **Validation**: Check for Zod, Yup, io-ts, etc.
+- **UI Components**: Check for shadcn/ui, Radix, MUI, etc.
+- **Styling**: Check for Tailwind (v3 or v4), CSS Modules, styled-components, etc.
+
+## Archetype Conventions
+
+### 00-core-definitions.md (TypeScript)
+
+- **Type aliases and union types**: Use `type` declarations for unions, intersections, utility types
+- **Core interfaces**: Define with `interface` keyword, JSDoc on every field
+- **Error class hierarchy**: Base error class extending `Error` with `code: string` property; domain-specific subclasses with typed properties
+- **Constants and enums**: Use `const` declarations and `as const` assertions; prefer string union types over `enum`
+- **Utility types**: Generic helpers like `Result<T, E>`, `Optional<T>`, etc.
+- **Barrel exports**: Export everything from `src/index.ts`
+
+### 01-architecture-layout.md (TypeScript)
+
+- **Package.json**: `name`, `exports` map (subpath exports like `.`, `./server`, `./client`, `./react`), `dependencies`, `devDependencies`, `scripts`
+- **tsconfig.json**: Key compiler options, extends root config
+- **Barrel export structure**: What each `index.ts` re-exports
+- **Build considerations**: Bundle vs unbundled, ESM vs CJS
+
+### Monorepo conventions
+
+- **Package naming**: `@repo/{name}` for shared packages, `@starter/{name}` for app-specific (adapt to project convention)
+- **Internal dependencies**: Reference as `@repo/{package}` in `package.json`
+- **Workspace protocol**: `"@repo/config": "workspace:*"` in pnpm, `"@repo/config": "*"` in bun
+
+## Spec Quality Rules
+
+- All TypeScript must be valid syntax — not pseudocode
+- Include complete interfaces with generics where applicable
+- Use discriminated unions for result types (e.g., `{ success: true; data: T } | { success: false; error: E }`)
+- Every interface field must have JSDoc explaining its purpose
+- Include explicit import paths in all code examples
+- Use `async/await` for asynchronous operations (not raw Promises)
+
+## Verification Specifics
+
+- **Type checking**: `bun run typecheck`, `tsc --noEmit`, or `npx tsc --noEmit`
+- **Barrel export validation**: Every `index.ts` re-exports what the spec says
+- **Cross-package type checks**: `bun run typecheck` (or equivalent) passes for both the feature package AND packages that depend on it
+- **Import path validation**: All import paths resolve correctly per the `exports` map in `package.json`
+
+### Runtime Entrypoints & Bootstrap-Wiring Sites
+
+Used by `CHECK-I22` (a runtime-required bootstrap needs a **non-test** caller on one of these) and
+`CHECK-I23` (a heavy init wired into a **universal** bootstrap entry should move to a lazier site).
+
+- **Runtime entrypoints (a legitimate non-test call site):** a `package.json` `bin` / CLI `main`; a
+  server entry that actually starts listening (`src/server.ts`, `src/index.ts` invoking `listen`); a
+  worker/consumer file; and for Next.js — `middleware.ts`, `app/**/route.ts` route handlers,
+  `app/**/{page,layout,template}.tsx`, server actions, and `instrumentation.ts`. Express/Hono/Fastify:
+  the file that constructs the app and calls `.listen()`.
+- **Universal bootstrap entries (run on every startup — the `CHECK-I23` risk site):** Next.js
+  `instrumentation.ts` / `instrumentation.js` (its `register()` runs once per server process before
+  any request), an app-server preload/`register`/`--import` hook, a root `app/layout.tsx` that
+  eagerly imports server singletons, and global test setup (`vitest.setup.ts`, `jest.setup.ts`) if it
+  bootstraps production graphs. Wiring a heavy init here loads it on **every** cold start (and, under
+  the dev server, on every module re-evaluation).
+- **Heavy server-only import markers (what makes an init "heavy" for `CHECK-I23`):** DB/ORM clients
+  (`drizzle-orm`, `@prisma/client`, `pg`, `mongoose`, `kysely`), queue/worker libs (`bullmq`, `bull`,
+  `kafkajs`, `ioredis`), telemetry/observability SDKs (`@opentelemetry/*`, `@sentry/node`), and a
+  whole-service-layer barrel (`import * as services from "@repo/services"`). An init that pulls any of
+  these into a universal bootstrap entry is the CHECK-I23 pattern — recommend lazy init at the first
+  route/handler/worker that needs it.
+
+## Testing
+
+- **Framework**: Vitest (most common in modern TS), Jest, or testing-library
+- **Test file location**: Co-located (`*.test.ts` next to source) or in `__tests__/` directories
+- **Fixture patterns**: Factory functions, test builders
+- **Type testing**: `expectTypeOf` from vitest for type-level assertions
+
+## Common Frameworks
+
+| Category | Options |
+|----------|---------|
+| Backend | Hono, Express, Fastify, Koa |
+| Frontend | React, Vue, Svelte, Solid |
+| Routing | TanStack Router, React Router, Next.js App Router |
+| Database | Drizzle, Prisma, TypeORM, Kysely |
+| Validation | Zod, Valibot, Yup, io-ts |
+| UI Components | shadcn/ui, Radix, MUI, Mantine |
+| Styling | Tailwind CSS, CSS Modules, styled-components, vanilla-extract |
+
+## Example: Project-Level Override
+
+Create `.feature-forge/stack-decisions.md` (legacy alias: `.claude/references/stack-decisions.md`) in your project root:
+
+```markdown
+# Stack Decisions
+
+## Runtime & Build
+- Bun 1.x for runtime and package management
+- Turborepo for monorepo orchestration
+
+## Backend
+- Hono for HTTP framework
+- Drizzle ORM with PostgreSQL
+- Zod for runtime validation
+
+## Frontend
+- React 19 with TanStack Router (SPA-first)
+- shadcn/ui component library
+- Tailwind CSS v4 with oklch color theming
+
+## Conventions
+- Barrel exports from index.ts in every package
+- Package naming: @repo/{name} for shared, @starter/{name} for app-specific
+- Vitest for testing
+```

package/adapters/pi/skills/forge-init/SKILL.md

@@ -0,0 +1,72 @@
+---
+# GENERATED — DO NOT EDIT. Source: skills/forge-init/SKILL.md. Regenerate: python3 scripts/build-adapters.py
+name: forge-init
+description: Initialize feature-forge configuration in the current project. Use when user runs /skill:forge-init or asks to set up forge for the first time. Creates forge.config.json with defaults. Do NOT trigger for general project initialization or setup tasks outside the forge pipeline.
+---
+
+# Initialize Feature Forge
+
+Run the initialization script to create `forge.config.json` with default settings:
+
+```bash
+R="$(bash -c 'for d in "${FEATURE_FORGE_ROOT:-}" "$HOME"/.claude/skills/feature-forge "$HOME"/.claude/plugins/cache/*/feature-forge/* "$HOME"/.claude/plugins/*/feature-forge "$HOME"/.agents/skills/feature-forge ./.agents/skills/feature-forge; do [ -x "$d/scripts/forge-root.sh" ] && exec "$d/scripts/forge-root.sh"; done')"
+[ -n "$R" ] || { echo "feature-forge: cannot locate plugin root" >&2; exit 1; }
+bash "$R/scripts/forge-init.sh"
+```
+
+After initialization, the config file will contain defaults for:
+- `specsDir`: `./specs`
+- `docsDir`: `./docs/architecture`
+- `backlogDir`: `null` (backlog lives alongside specs)
+- `gitCommitAfterStage`: `true`
+- `commitPrefix`: `forge`
+- `stack`: `null` (detected during `/skill:forge-2-tech`)
+- `typeCheckCommand`: `null` (set during `/skill:forge-2-tech`)
+- `testCommand`: `null` (set during `/skill:forge-2-tech`)
+- `smokeCommand`: `null` (optional end-to-end smoke that boots the wired app and drives one request; set it to enable impl-verify's runnability check `CHECK-I21` — distinct from `testCommand`)
+- `autoInvokeNextStage`: `true` (the navigator auto-starts the next stage after you confirm; set `false` to only print the command)
+- `contextWindowTokens`: `null` (the navigator infers the context window; set to your model's window, e.g. `1000000` for a 1M-context model, for accurate context-usage advice)
+- `contextWarnThreshold`: `0.7` (fraction of the window past which the navigator suggests a clean session)
+- `autoVerify`: `false` (set `true` to run `forge-verify` automatically after each authoring stage completes — in-stage, in the same session, before the exit block; it costs an extra clean-room verify per stage, so it trades a little time/tokens for catching errors early)
+- `autoVerifyStages`: `{}` (per-stage overrides for `autoVerify`)
+- `autoFix`: `false` (set `true` to chain `forge-fix` after an auto-verify finds issues)
+
+If `forge.config.json` already exists, the script will not overwrite it.
+
+## Offer auto-verify
+
+The template writes `autoVerify: false`. After the config is created (and only when the script
+actually created it — skip this if it reported the file already exists), offer to turn
+auto-verify on, then write the choice back into `forge.config.json`.
+
+If the `AskUserQuestion` tool is available, ask exactly one question:
+
+> **Enable auto-verify?** Verification runs in a clean-room subagent in-stage after each
+> authoring stage completes — in the same session, before the exit block, so any fix
+> decision keeps its context. It never needs a `/new` and only returns a compact digest.
+> **Recommended: on.** (Change later by editing `autoVerify` in `forge.config.json`.)
+
+Options: **Enable (recommended)** / **Leave off**.
+
+- On **Enable**: patch `"autoVerify": false` → `"autoVerify": true` in the generated
+  `forge.config.json` in place, preserving formatting and every other key.
+- On **Leave off**: leave the config as written (`autoVerify: false`).
+
+If the host lacks a structured question tool but can still prompt the user (e.g. Codex asks in
+plain text), use that — ask the one question directly and wait for the reply; it is the same
+choice, just rendered differently. Only when the host has **no** way to ask at all (a fully
+non-interactive / headless run) do you skip the prompt: leave `autoVerify: false` and print the
+one-line note `Set "autoVerify": true in forge.config.json to verify automatically after each stage.`
+
+After initialization, start the pipeline with `/skill:forge-1-prd <feature-name>`.
+
+---
+
+## Host execution notes (Pi)
+
+This Pi bundle preserves Claude's `AskUserQuestion` references because it ships a Pi compatibility extension registering an `AskUserQuestion` tool. On Pi:
+
+- **User input:** use `AskUserQuestion` for genuine user decisions. It supports multiple questions, option descriptions, recommended ordering, multi-select, previews, and free-form Other/custom answers.
+- **Skill dispatch:** Pi uses `/skill:<name>` commands. If you cannot invoke a skill directly, print the exact `/skill:<name> ...` command for the user to run.
+- **Subagents:** this bundle declares its custom agents (`forge-researcher`, `forge-spec-writer`, `forge-verifier`) as package agents. If a `subagent` tool is registered, dispatch one with `{ agent: "forge-verifier", task: "..." }`, or fan several out concurrently with `{ tasks: [{ agent: "forge-spec-writer", task: "..." }, ...] }`. If no `subagent` tool is available, run that step inline yourself.
+- **Background / monitoring:** run long-lived commands in the foreground and report progress as it arrives.