@jaimevalasek/aioson 1.30.2 → 1.36.0

package/template/.aioson/skills/process/sheldon-expansion-audit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sheldon-expansion-audit
-description: "Sheldon process skill for auditing a PRD against prior feature expansion artifacts and expected product richness. Use in @sheldon when expansion-scout.md or scope-expansion.md exists, or when a PRD for a rich-surface feature looks too thin, too inflated, or lacks acceptance criteria for enriched capabilities."
+description: "Sheldon process skill for auditing a PRD against prior feature expansion artifacts, expected product richness, and operational surface completeness. Use in @sheldon when expansion-scout.md or scope-expansion.md exists, or when a PRD for a rich-surface feature looks too thin, too inflated, lacks acceptance criteria for enriched capabilities, or implies workspaces, boards, cards, pipelines, operational CRUD, admin/management surfaces, or Trello/CRM/Kanban-like behavior."
 ---
 
 # Sheldon Expansion Audit
@@ -20,6 +20,22 @@ Read available inputs:
 
 If no prior expansion artifact exists, perform only a lightweight inferred expansion and label it clearly.
 
+## Operational Surface Audit
+
+Before recommending enrichment, audit the PRD against the Operational Surface Map in `.aioson/docs/feature-expansion-taxonomy.md`.
+
+Flag as **critical** when a Core object exists in scope but lacks:
+
+- parent/owner relationship
+- create, list/view, edit, delete/archive, or restore handling
+- a management surface where the user performs those actions
+- empty state and validation/error behavior
+- role/permission boundary for owner/member/admin scenarios
+
+For Trello/Kanban/CRM/workspace-like PRDs, missing workspace management, board/pipeline CRUD, primary item creation/editing, or the main work surface is a blocking product gap, not optional enrichment.
+
+Do not allow generic phrases like "manage cards", "manage boards", or "workspace support" to pass unless the PRD names the surfaces and flows that make those capabilities usable.
+
 ## Output
 
 Write `.aioson/context/features/{slug}/expansion-audit.md`.
@@ -43,6 +59,10 @@ Use this structure:
 - Missing user states/actions:
 - Missing acceptance criteria:
 
+## Operational Surface Audit
+| Object | Expected surface | Missing action/state | Severity | Required PRD patch |
+|---|---|---|---|---|
+
 ## Too Large Check
 - V2 items pulled into MVP:
 - Optional items without approval:
@@ -61,7 +81,8 @@ Proceed / enrich PRD first / return to product for decision.
 
 - Prefer evidence from prior expansion artifacts over inventing new ideas.
 - Flag when a rich-surface PRD has only generic fields or thin CRUD.
+- Treat missing Core management surfaces and create/edit flows as critical gaps.
+- For Trello-like products, workspace/board management and card creation/editing are Core unless explicitly excluded in the PRD.
 - Flag when V2 ideas entered MVP without explicit rationale.
 - Convert accepted expansion items into acceptance-criteria gaps.
 - Do not rewrite Product-owned Vision, Problem, or Users.
-

package/template/.aioson/skills/static/multi-agent-patterns.md

@@ -28,11 +28,11 @@ When Evaluator finds issues:
 
 ### Session isolation
 
-Each role should run from a compact operational handoff:
-- Planner sessions: produce artifacts, then /compact for same-feature continuation
-- Generator sessions: read spec pack + implement, then /compact for same-feature continuation
-- Evaluator sessions: read code + spec + verify, then /compact for same-feature continuation
-- Use /clear only for a hard reset, feature switch, polluted context, or security-sensitive reset
+Each role should run from a compact operational handoff:
+- Planner sessions: produce artifacts, then /compact for same-feature continuation
+- Generator sessions: read spec pack + implement, then /compact for same-feature continuation
+- Evaluator sessions: read code + spec + verify, then /compact for same-feature continuation
+- Use /clear only for a hard reset, feature switch, polluted context, or security-sensitive reset
 
 Cross-role communication happens through artifacts on disk, not conversation history.
 

package/template/CLAUDE.md

@@ -7,15 +7,15 @@ You operate as AIOSON.
    - If missing: run `/setup`
    - If present: read it before any action
 2. Read `.aioson/config.md` only if project context is missing/invalid, setup/routing policy is needed, or the active agent explicitly asks for config details.
-3. If `.aioson/rules/` contains `.md` files, note silently that project rules are active — concrete code/review agents use `context:brief` for precision selection, broad recall, and constraints. Load `must_load`, treat `related` as recall hints, and keep `context:select` as the underlying selector/fallback when the CLI or agent contract asks for it. Do not alarm if the directory is absent or empty.
+3. If `.aioson/rules/` contains `.md` files, note silently that project rules are active — concrete code/review agents use `context:brief` for precision selection, broad recall, and constraints. Load `must_load`, treat `related` as recall hints, and keep `context:select` as the underlying selector/fallback when the CLI or agent contract asks for it. Do not alarm if the directory is absent or empty.
 
-## Project knowledge
-
-Read `.aioson/learnings/INDEX.md` if it exists. Each line is a project gotcha or recipe with its file path and a one-line summary. Lazy-load individual files only when title/scope matches your current task or files being touched.
-
-## Canonical context paths
-
-When instructions mention context artifacts by bare filename — `project.context.md`, `project-pulse.md`, `features.md`, `dev-state.md`, `workflow.state.json`, `last-handoff.json`, or `handoff-protocol.json` — resolve them to `.aioson/context/<filename>`. Never probe the project root or `.aioson/` root for these files.
+## Project knowledge
+
+Read `.aioson/learnings/INDEX.md` if it exists. Each line is a project gotcha or recipe with its file path and a one-line summary. Lazy-load individual files only when title/scope matches your current task or files being touched.
+
+## Canonical context paths
+
+When instructions mention context artifacts by bare filename — `project.context.md`, `project-pulse.md`, `features.md`, `dev-state.md`, `workflow.state.json`, `last-handoff.json`, or `handoff-protocol.json` — resolve them to `.aioson/context/<filename>`. Never probe the project root or `.aioson/` root for these files.
 
 ## No agent selected
 
@@ -94,8 +94,12 @@ AIOSON follows a Spec-Driven Development (SDD) methodology. Key governance files
 
 The process depth scales with project classification:
 - **MICRO** (0-1): lightweight — @product → @dev
-- **SMALL** (2-3): standard — @product → @analyst → @scope-check(pre-dev) → @architect → @discovery-design-doc → @dev, with optional @scope-check(post-dev) before @qa when implementation drift is likely
-- **MEDIUM** (4-6): full — all agents, all gates, all artifacts
+- **SMALL** (2-3): lean by default — @product → @sheldon → @dev → @qa (@sheldon is the single spec authority)
+- **MEDIUM** (4-6): @orchestrator maestro — feature: @product → @orchestrator → @dev → @pentester → @qa; project: @setup → @product → @orchestrator → @dev → @qa. @orchestrator is the MEDIUM single spec authority (the "maestro"): it fans out to @analyst + @architect + @pm (+ @ux-ui when UI-heavy) as sub-agents, then consolidates/verifies/redoes their work into one gated spec package (requirements + spec[Gates A/B/C approved] + design-doc + readiness + implementation-plan[approved] + harness-contract) and hands to @dev — the horizontal (fan-out) counterpart to @sheldon's lean lane (SMALL). @analyst, @architect, @pm, @discovery-design-doc, @scope-check, and @ux-ui are no longer default hops; they are sub-agents the orchestrator invokes and remain opt-in detours. @architect's merged mode survives only for the opt-in full-chain detour that routes @architect → @dev without @discovery-design-doc. The deterministic drift check runs at the @dev/@qa done gate.
+
+**Lean lane (default for SMALL):** collapse the spec hops into @sheldon as the single spec authority — @product → @sheldon → @dev → @qa (@validator detour when a harness contract exists). Lean is the SMALL default; the heavier multi-agent "full-merged" preset stays an opt-in escape hatch via `.aioson/context/workflow.config.json`. See `.aioson/docs/workflow-lean-lane.md`.
+
+**Runtime smoke gate (all lanes):** a feature with a backend, a database, or a clickable prototype does not close until its build + migrations (applied to a real DB) + boot + Core happy-path run on the **real stack** — not just unit tests. Enforced by @qa's Runtime smoke gate, the §2c `RG-*` criteria in `harness-contract.json`, and @validator's contract-integrity precheck. Passing unit tests + `tsc` is the floor, not "done".
 
 Classification is determined by @analyst during discovery. See `aioson-spec-driven` skill for details.
 
@@ -108,7 +112,7 @@ When running Claude Code directly (without `aioson workflow:next`), these rules
 **Hard constraints — no exceptions:**
 - You MUST NEVER implement code, produce UI specs, write PRDs, or answer technical tasks outside an activated agent.
 - If the user explicitly activates `/deyvin` or `/pair`, it may act directly only for continuity on existing known context and a small validated slice. If the request is a new project, greenfield build, new feature, broad redesign, vague or contradictory, or mixes product + UX + implementation scope, `/deyvin` must hand off immediately and must not code first.
-- Between agent handoffs, your ONLY valid output is: which agent is next and why. Do not continue into that agent's work. Single exception: when `auto_handoff: true` is set in `.aioson/context/project.context.md`, the agents covered by `.aioson/docs/autopilot-handoff.md` auto-invoke the next agent's skill instead of stopping. That chain stops before the first `@dev` activation (the human clears context and starts implementation) and resumes through the post-dev review cycle (`@dev` → `@qa` → `@tester`/`@pentester` when their `@qa` triggers fire → `@validator`); it never auto-runs `feature:close`/publish — those require explicit human approval.
+- Between agent handoffs, your ONLY valid output is: which agent is next and why. Do not continue into that agent's work. Single exception: when `auto_handoff: true` is set in `.aioson/context/project.context.md`, the agents covered by `.aioson/docs/autopilot-handoff.md` auto-invoke the next agent's skill instead of stopping. That chain stops before the first `@dev` activation (the human clears context and starts implementation) and resumes through the post-dev review cycle (`@dev` → `@qa` → `@tester`/`@pentester` when their `@qa` triggers fire → `@validator`); it never auto-runs `feature:close`/publish — those require explicit human approval.
 - If the user sends an implementation request before setup is complete: do not implement. Tell them to activate `/setup` first.
 - If the user insists on bypassing an agent stage: refuse and redirect. Urgency or complexity do not override this rule.