pi-aia-asf 0.4.0 → 0.5.0

package/CHANGELOG.md

@@ -7,6 +7,25 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.5.0] - 2026-08-28
+
+### Added
+
+- **06b Rule 15 — bound every long-running operation** (new mandatory QA rule):
+  state the expected duration before running any long command (package installs,
+  platform/test-harness startup, browser/daemon launches, full suites); ALWAYS
+  wrap it in a hard timeout (`timeout N …` / tool timeout parameter); exceeding
+  the bound is a bug signal — kill and diagnose the root cause; if the bound
+  proves too short, raise it deliberately with a reason. Rooted in the user
+  report of package hangs lasting up to 50,000 seconds with the agent waiting
+  idle. Added to the Rule 10 definition-of-done checklist.
+- **SKILL.md discipline rule 6 — Bounded waits — ALWAYS** (renumbered rules
+  7–10): the same rule at the phase level, with the 50,000-second hang as the
+  anti-example.
+- **07-release.md**: "Verify first" step now requires every long-running
+  verification command to have run under an explicit timeout with a stated
+  expected duration.
+
 ## [0.4.0] - 2026-08-28
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-aia-asf",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "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, pi-aia-browser, and pi-intercom.",
   "keywords": [
     "pi-package",

package/skills/aia-asf/SKILL.md

@@ -200,10 +200,11 @@ Execute the task list milestone by milestone. Discipline rules:
 3. **No scope creep**: if something new is discovered that changes specs, capture it, ask the user, and update the plan before implementing.
 4. **Descriptive commits**: `git commit -m "type: specific description of what and why"` (e.g. `fix: verify specs before rotation`). No vague messages, no placeholders.
 5. **Browser testing — MANDATORY for any web interface**: if the deliverable has a UI/website/web app, test it through `pi-aia-browser` (`browser_init`, `browser_navigate`, `browser_click`, `browser_type`, `browser_screenshot`, `browser_dom`, …) to replicate the user's real experience — not just curl/API checks. Verify: loads, key user journeys, responsive behavior, console errors. **Silent async paths included**: ingest through the real flow and wait for the enrichment to land (06b Rule 9).
-6. **Let pi-vigilant do its job**: it will auto-continue after premature stops and verify specs at settle. When it asks for `update_spec_status` with evidence, do it.
-7. **CHANGELOG discipline**: every user-visible change gets a CHANGELOG entry describing exactly what changed (no placeholder text).
-8. **Challenge approved designs (M4)**: if a spec's literal reading creates product tension (e.g. feedback clusters under "Plan" when "Plan = plans"), stop and resolve it with the user before implementing — never implement blindly and call it delivered.
-9. **Trace before claiming delivered (M5)**: the delivery log is a claim; the code is the evidence. Before marking anything ✅, trace the actual code path, confirm the output is consumed by a surface, and confirm the operator-facing outcome test passes.
+6. **Bounded waits — ALWAYS (06b Rule 15)**: before any long-running command (package install, platform/test-harness startup, browser/daemon launch, full suite), **state the expected duration explicitly** and wrap it in a **hard timeout** (`timeout N …` or the tool's `timeout` parameter) — never run unbounded. If it exceeds the bound: kill it, diagnose what it is blocking on, fix the root cause. If the bound proves too short, raise it deliberately with a reason — never silently extend, never remove the bound. A 50,000-second hang is a failure to investigate, not patience.
+7. **Let pi-vigilant do its job**: it will auto-continue after premature stops and verify specs at settle. When it asks for `update_spec_status` with evidence, do it.
+8. **CHANGELOG discipline**: every user-visible change gets a CHANGELOG entry describing exactly what changed (no placeholder text).
+9. **Challenge approved designs (M4)**: if a spec's literal reading creates product tension (e.g. feedback clusters under "Plan" when "Plan = plans"), stop and resolve it with the user before implementing — never implement blindly and call it delivered.
+10. **Trace before claiming delivered (M5)**: the delivery log is a claim; the code is the evidence. Before marking anything ✅, trace the actual code path, confirm the output is consumed by a surface, and confirm the operator-facing outcome test passes.
 
 ---
 

package/skills/aia-asf/references/06b-testing-qa.md

@@ -146,6 +146,7 @@ never arrives, the wiring is dead — that is a failed test.
 - [ ] **Consumed by a surface: every delivered feature's output is visible in the product (UI or API) — nothing ships as dead machinery**
 - [ ] **E2E behavioral test: every feature spec has a test through the real entry point asserting the operator-facing outcome**
 - [ ] Unverifiable specs → `partial` + asked the user (never self-certified)
+- [ ] **Every long-running command ran under an explicit timeout with a stated expected duration (no unbounded waits)**
 
 ## Rule 11 — Report honestly
 
@@ -194,3 +195,24 @@ done — the wiring may be dead.
 - **Scale note:** mandatory for feature specs in **large/gated work**. For small
   work, required only when the change touches a surface/wiring; otherwise the
   standard test-first rules above suffice.
+
+## Rule 15 — Bound every long-running operation: state the expected duration, then enforce it
+
+> **Real failure (user report):** package installs / platform startups / test
+> harnesses hung for up to **50,000 seconds** while the agent waited, doing
+> nothing. An unbounded wait is not patience — it is a silent stall.
+
+- **State the expected duration before running.** "This install should take
+  ~2 min", "first platform startup ~10 min", "suite ~3 min". The expectation is
+  part of the command, not an afterthought.
+- **ALWAYS wrap it in a hard timeout** — `timeout 300 …` for shell commands, an
+  explicit `timeout` parameter for tool calls. Never run unbounded.
+- **Exceeding the bound is a bug signal, not a slow command.** Kill it and
+  diagnose immediately: what is it blocking on (network, lock, hung process,
+  missing dependency, waiting for input)? Fix the root cause.
+- **If the bound proves too short, raise it deliberately** — state the new
+  expectation and the reason ("first-time platform startup needs 10 min;
+  bound raised to 900s"). Never silently extend, never remove the bound.
+- **A hang that outlives its expected duration is a failure to investigate,**
+  not a wait to endure. If you cannot verify something within a bounded time,
+  say so explicitly (Rule 11) instead of waiting indefinitely.

package/skills/aia-asf/references/07-release.md

@@ -15,6 +15,7 @@ Publishing is **always the user's decision**. The factory prepares everything; t
    - typecheck / build passes
    - test suite green
    - all MUST specs `met` in pi-vigilant
+   - every long-running verification command ran under an explicit timeout with a stated expected duration (06b Rule 15) — no unbounded waits
 2. **Version bump** — semantic versioning:
    - `patch` (0.1.0 → 0.1.1): bug fixes
    - `minor` (0.1.0 → 0.2.0): new features, backward compatible