pi-aia-asf 0.2.0 → 0.2.1

package/CHANGELOG.md

@@ -7,6 +7,23 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.2.1] - 2026-08-14
+
+### Added
+
+- **Scale-based flow.** Every ASF activation is now classified **small** or **large**:
+  - **Small** (small features, minor bugfixes, small refactors) — runs **automatically**: no intake question barrage (at most one clarifying question), no research, no adversarial gate, no PLAN.md, no approval. State the intent, capture specs silently, implement test-first, verify, deliver.
+  - **Large** (new projects, significant features, major bugfixes, architectural refactors) — full gated flow unchanged: intake → research → specs → adversarial → PLAN.md → **explicit approval** → implementation → verification.
+  - When in doubt, **default to small and start working**; re-classify upward if the work grows.
+- **`/asf small`** command — starts a small session directly in implementation phase. `/asf status` now shows the scale (`automatic — no gates` for small).
+
+### Changed
+
+- All gates (1–5) explicitly apply to large work only; Phase 2 (research) and Phase 5 (PLAN.md + approval) are skipped entirely for small work.
+- References `01-intake`, `04-adversarial`, `05-plan` annotated with the scale rule.
+- Anti-patterns: no question barrage or PLAN.md/approval demand for small work; when in doubt, start small.
+
+
 ## [0.2.0] - 2026-08-14
 
 ### Added

package/index.ts

@@ -30,8 +30,11 @@ type AsfPhase =
   | "implementation"
   | "verification";
 
+type AsfScale = "small" | "large";
+
 interface AsfState {
   workType?: "new-project" | "feature" | "major-bugfix" | "refactor";
+  scale?: AsfScale;
   phase: AsfPhase;
   planApproved?: boolean;
   startedAt?: string;
@@ -160,7 +163,7 @@ export default function register(pi: ExtensionAPI): void {
   // Startup check: warn once per session if deps are missing (unless disabled)
   // The extension loads at startup; log to console so it surfaces in logs.
 
-  const setPhase = async (ctx: ExtensionCommandContext, phase: AsfPhase, workType?: AsfState["workType"]): Promise<string> => {
+  const setPhase = async (ctx: ExtensionCommandContext, phase: AsfPhase, workType?: AsfState["workType"], scale?: AsfScale): Promise<string> => {
     const project = projectName();
     const state = await loadState(project);
     const now = new Date().toISOString();
@@ -183,6 +186,7 @@ export default function register(pi: ExtensionAPI): void {
         };
       }
       if (workType) state.current.workType = workType;
+      if (scale) state.current.scale = scale;
       state.current.phase = phase;
       state.current.updatedAt = now;
     }
@@ -196,13 +200,15 @@ export default function register(pi: ExtensionAPI): void {
 
     switch (sub) {
       case "new":
-        return await setPhase(ctx, "intake", "new-project");
+        return await setPhase(ctx, "intake", "new-project", "large");
       case "feature":
-        return await setPhase(ctx, "intake", "feature");
+        return await setPhase(ctx, "intake", "feature", "large");
       case "bugfix":
-        return await setPhase(ctx, "intake", "major-bugfix");
+        return await setPhase(ctx, "intake", "major-bugfix", "large");
       case "refactor":
-        return await setPhase(ctx, "intake", "refactor");
+        return await setPhase(ctx, "intake", "refactor", "large");
+      case "small":
+        return await setPhase(ctx, "implementation", undefined, "small");
       case "status": {
         const project = projectName();
         const state = await loadState(project);
@@ -210,6 +216,7 @@ export default function register(pi: ExtensionAPI): void {
         return (
           `ASF status (${project}):\n` +
           `  work type: ${state.current.workType || "unset"}\n` +
+          `  scale: ${state.current.scale || "unset"}${state.current.scale === "small" ? " (automatic — no gates)" : ""}\n` +
           `  phase: ${state.current.phase}\n` +
           `  plan approved: ${state.current.planApproved ? "yes" : "no"}\n` +
           `  started: ${state.current.startedAt || "?"}\n` +
@@ -236,10 +243,11 @@ export default function register(pi: ExtensionAPI): void {
       default:
         return (
           "ASF commands:\n" +
-          "  /asf new        — start a new software project\n" +
-          "  /asf feature    — add a feature to an existing project\n" +
-          "  /asf bugfix     — major bugfix\n" +
-          "  /asf refactor   — architectural refactor\n" +
+          "  /asf new        — start a new software project (large, gated)\n" +
+          "  /asf feature    — add a feature to an existing project (large, gated)\n" +
+          "  /asf bugfix     — major bugfix (large, gated)\n" +
+          "  /asf refactor   — architectural refactor (large, gated)\n" +
+          "  /asf small      — small change, automatic (no gates)\n" +
           "  /asf status     — show current phase\n" +
           "  /asf verify     — run the definition-of-done QA gate\n" +
           "  /asf abort      — end the current session\n\n" +

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-aia-asf",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "description": "Ai Applied Agentic Software Factory — codifies the full software development flow: intake, research, spec capture, adversarial analysis, planning with approval gates, test-first implementation, and release. Requires pi-vigilant, pi-smart-web-search, pi-smart-fetch, and pi-aia-browser.",
   "keywords": [
     "pi-package",

package/skills/aia-asf/SKILL.md

@@ -4,15 +4,17 @@ description: >-
   Agentic Software Factory — run a complete, disciplined software development
   cycle. Use when the user wants to start a NEW software project, add a
   SIGNIFICANT FEATURE to an existing project, perform a MAJOR BUGFIX, or do an
-  ARCHITECTURAL REFACTOR. The flow classifies the work, asks questions until the
-  intent is clear, researches SOTA and existing packages, captures hard
-  specifications (via capture_spec, shared with pi-vigilant), runs adversarial
-  analysis, produces a PLAN.md and gets explicit user approval, then implements
-  test-first with strict codebase isolation and mandatory browser testing of any
-  web interfaces (pi-aia-browser). Do NOT activate for simple Q&A, one-line
-  fixes, casual conversation, content writing, or non-software tasks. When in
-  doubt about whether work qualifies as a project/feature/bugfix/refactor, ask
-  the user.
+  ARCHITECTURAL REFACTOR — and also for SMALL software changes (small features,
+  minor bugfixes, small refactors), which run AUTOMATICALLY with no intake
+  questions, no PLAN.md, and no approval. LARGE work (new projects, significant
+  features, major bugfixes, architectural refactors) runs the full gated flow:
+  classify, ask until intent is clear, research SOTA and packages, capture hard
+  specifications (via capture_spec, shared with pi-vigilant), run adversarial
+  analysis, produce a PLAN.md and get explicit user approval, then implement
+  test-first with strict codebase isolation and mandatory browser testing of web
+  interfaces (pi-aia-browser). Do NOT activate for simple Q&A, one-line fixes,
+  casual conversation, content writing, or non-software tasks. When in doubt,
+  ask the user.
 ---
 
 # AIA Agentic Software Factory (ASF)
@@ -28,24 +30,35 @@ You are running the **Ai Applied Agentic Software Factory**. This skill codifies
 
 ## Phase 0 — Classify the work (gate)
 
-Determine the work type. If it is not ASF work, **do not run the factory** — just help normally.
+Determine the work type **and scale**. If it is not ASF work, **do not run the factory** — just help normally.
 
-| Work type | ASF? |
-|---|---|
-| New software project | ✅ yes — full flow |
-| Significant feature in an existing project | ✅ yes — full flow (research: medium depth) |
-| Major bugfix (multi-file, behavior change, needs tests) | ✅ yes — lighter flow (research optional) |
-| Architectural refactor | ✅ yes — full flow (research: low depth) |
-| Simple Q&A, one-liner fix, casual talk, docs-only | ❌ no |
-| Non-software tasks (LinkedIn, research-only, writing) | ❌ no |
+| Work type | ASF? | Scale | Flow |
+|---|---|---|---|
+| New software project | ✅ | **large** | full flow |
+| Significant feature | ✅ | **large** | full flow (research: medium) |
+| Small feature | ✅ | **small** | automatic |
+| Major bugfix (multi-file, behavior change, needs tests) | ✅ | **large** | lighter flow (research optional) |
+| Minor bugfix (one area, no contract change) | ✅ | **small** | automatic |
+| Architectural refactor | ✅ | **large** | full flow (research: low) |
+| Small refactor (renames, restructure of one module) | ✅ | **small** | automatic |
+| Simple Q&A, one-liner fix, casual talk, docs-only | ❌ | — | — |
+| Non-software tasks (LinkedIn, research-only, writing) | ❌ | — | — |
+
+**Scale rule — the core behavior difference:**
+
+- **Large work** runs the full gated flow: intake questions → research → specs → adversarial → PLAN.md → **explicit approval** → implementation → verification.
+- **Small work runs automatically**: no intake question barrage (at most ONE clarifying question, only if truly ambiguous), no research, no PLAN.md, no approval gate. State the intent in one or two sentences, capture specs, implement test-first, verify, deliver. Do not ask permission to start; do not stop for sign-off. If it turns out to be larger than expected mid-way, re-classify, say so, and switch to the full flow with approval.
+- When in doubt about scale, **default to small and start working** — the user prefers action over questions. Re-classify upward if the work grows.
 
 If the user's request is ambiguous, **ask** before starting. State the classification explicitly:
-`ASF: <new-project|feature|major-bugfix|refactor> — starting Phase 1 (intake).`
+`ASF: <new-project|feature|major-bugfix|refactor> <large|small> — starting Phase 1 (intake).`
 
 ---
 
 ## Phase 1 — Intake: ask until it's clear (gate)
 
+> **Scale check — applies to LARGE work only.** For **small** work: skip the question bank. If the request is clear enough to act, state your understanding in one or two sentences and proceed immediately. Ask at most ONE clarifying question, and only when genuinely ambiguous.
+
 The factory **keeps asking until all is clear**. Never start planning or implementation on guesses.
 
 Minimum intake checklist (ask anything not yet known, one question at a time or a short batch):
@@ -60,12 +73,14 @@ Minimum intake checklist (ask anything not yet known, one question at a time or
 
 For each answer, **capture hard requirements immediately with `capture_spec`** (requirement, area, priority). Specs are the shared contract with pi-vigilant — it will re-verify them at the end.
 
-**Gate 1**: You may only leave intake when the user has confirmed the summary of intent (restate it back in 3–5 bullet points and ask "is this correct?").
+**Gate 1** (large only): You may only leave intake when the user has confirmed the summary of intent (restate it back in 3–5 bullet points and ask "is this correct?"). Small work does not pass through this gate.
 
 ---
 
 ## Phase 2 — Research: SOTA and packages (adaptive depth)
 
+> **Small work skips research entirely.** If implementation needs a library you don't know, a single quick search is enough — no research summary, no Gate 2.
+
 | Work type | Research depth |
 |---|---|
 | New project | **Mandatory, full** — SOTA approaches, frameworks, existing packages, reference implementations |
@@ -80,7 +95,7 @@ Research method (use `web_search` + `web_fetch`/`batch_web_fetch`):
 4. **Cite sources** in the research summary — every claim about a package/library gets a URL
 5. Summarize findings + a **recommendation** (which approach, which packages, with rationale)
 
-**Gate 2**: present the research summary + recommendation to the user. Ask: "proceed with this approach, or adjust?" Do not enter planning until the approach is agreed.
+**Gate 2** (large only): present the research summary + recommendation to the user. Ask: "proceed with this approach, or adjust?" Do not enter planning until the approach is agreed.
 
 ---
 
@@ -94,12 +109,14 @@ Turn the intake answers + research into the authoritative spec set.
 4. Default priority is `must`; use `should` only when the user says "nice to have".
 5. Areas: functionality, ui-ux, performance, security, error-handling, testing, documentation, compatibility, constraints, format, data, deployment, other.
 
-**Gate 3**: show the full spec tree (`get_task_specs`) and get user sign-off: "specs correct — proceed to adversarial analysis?"
+**Gate 3** (large only): show the full spec tree (`get_task_specs`) and get user sign-off: "specs correct — proceed to adversarial analysis?" Small work: capture specs silently, no sign-off needed.
 
 ---
 
 ## Phase 4 — Adversarial analysis (gate)
 
+> **Small work:** skip the formal gate. Do a quick mental pass over edge cases and failure modes while implementing; if something real surfaces, fix it or capture a spec. No user checkpoint.
+
 Challenge the plan like a hostile reviewer before committing to it. For each spec and the overall design, ask and resolve:
 
 - **Edge cases** — empty input, zero users, max load, missing data, concurrency
@@ -112,12 +129,14 @@ Challenge the plan like a hostile reviewer before committing to it. For each spe
 
 For each finding: either capture a new spec, refine an existing one (supersede), or record the decision to accept the risk. **Ask the user about anything that changes scope.**
 
-**Gate 4**: summarize adversarial findings + resolutions, get user confirmation.
+**Gate 4** (large only): summarize adversarial findings + resolutions, get user confirmation.
 
 ---
 
 ## Phase 5 — Plan + approval gate
 
+> **Small work: SKIP this phase entirely.** No PLAN.md, no approval — go straight to Phase 6 (implementation).
+
 Write `PLAN.md` in the project root (repo root, or cwd if no repo). Structure:
 
 ```markdown
@@ -136,10 +155,10 @@ Write `PLAN.md` in the project root (repo root, or cwd if no repo). Structure:
 
 Keep the plan **implementation-ready**: any competent engineer (or agent) can execute the task list without re-deriving decisions.
 
-**Gate 5 — MANDATORY user approval**: present the plan and ask explicitly:
+**Gate 5 — MANDATORY user approval (large only)**: present the plan and ask explicitly:
 > "Plan ready. Do you approve starting implementation? (yes / changes needed)"
 
-**Never start implementing before Gate 5 passes.** If the user says "go" without reading, still show the plan and confirm.
+**Never start implementing before Gate 5 passes — for LARGE work.** If the user says "go" without reading, still show the plan and confirm. Small work never reaches this gate.
 
 ---
 
@@ -201,6 +220,9 @@ Run the **Definition of Done checklist** in `references/06b-testing-qa.md` (Rule
 - ❌ Guessing at a fix before reading the actual error message
 - ❌ Fixing a bug without adding a regression test
 - ❌ Claiming something was verified when it was assumed
+- ❌ Asking a barrage of intake questions for small work — small runs automatically
+- ❌ Writing PLAN.md / demanding approval for small work — that's the large-work gate only
+- ❌ Waiting for sign-off when the work is small; when in doubt, default to small and start
 
 ## References
 

package/skills/aia-asf/references/01-intake.md

@@ -1,5 +1,9 @@
 # Phase 1 — Intake: Question Bank
 
+> **Scale note: this bank is for LARGE work.** Small work (small features, minor
+> bugfixes, small refactors) skips the questions — state understanding in 1–2
+> sentences and start. At most ONE clarifying question, only if genuinely ambiguous.
+
 Keep asking until the user confirms. One question at a time is fine; short batches (3–5) are faster. Do not proceed on guesses.
 
 ## Starter questions
@@ -32,3 +36,5 @@ Every concrete requirement the user states → `capture_spec` immediately, befor
 ## Intake gate
 
 Restate intent in 3–5 bullets, then ask: **"Is this correct?"** Only proceed on an explicit yes.
+
+> Large work only. Small work has no intake gate.

package/skills/aia-asf/references/04-adversarial.md

@@ -1,5 +1,9 @@
 # Phase 4 — Adversarial Analysis Checklist
 
+> **Scale note: the full checklist and gate apply to LARGE work.** Small work does
+> a quick mental pass on edge cases and failure modes while implementing — no
+> formal review, no user checkpoint.
+
 Challenge every spec and design decision like a hostile reviewer. For each item, determine: capture a new spec / supersede an existing one / accept the risk (recorded).
 
 ## Per-spec questions

package/skills/aia-asf/references/05-plan.md

@@ -1,5 +1,8 @@
 # Phase 5 — PLAN.md Template
 
+> **Scale note: this phase is for LARGE work only.** Small work skips PLAN.md and
+> the approval gate entirely — implement directly.
+
 Write `PLAN.md` in the project root. It must be executable by any competent engineer without re-deriving decisions.
 
 ```markdown
@@ -54,7 +57,7 @@ From adversarial analysis. Each risk: likelihood, impact, mitigation, owner.
 Explicitly cut items (so nobody re-adds them).
 ```
 
-## Approval gate (MANDATORY)
+## Approval gate (MANDATORY — large work only)
 
 Present the plan and ask: