bigpowers 2.76.3 → 2.77.0

package/.pi/skills/plan-release/SKILL.md

@@ -38,7 +38,6 @@ specs/epics/e01-auth-system/
 **Rationale:** Capsule dirs achieve change isolation (C9), enable archive pruning (C2/C6), and enforce SRP by decoupling spec `.md` from execution `-tasks.yaml` (C1).
 
 ## Process
-
 ### 1. Draft epics and stories
 
 From the conversation context, define:
@@ -48,15 +47,12 @@ From the conversation context, define:
 WSJF-sort epics: score = (Business Value + Time Criticality + Risk Reduction) / Job Size. Highest score first.
 
 > **Security risk boost:** If an epic's `specs/security/epics/<id>/THREAT_MODEL.md` identifies HIGH or CRITICAL risk, add +2 to the WSJF numerator (BV + TC + RR + 2) to reflect the urgency of addressing security concerns before they ship. Document the boost in the epic's note field in release-plan.yaml.
-
 ### 2. Write acceptance criteria (Gherkin)
 
 For each story, write at least one happy-path and one edge-case scenario (countable format §17 if maturity ≥ 3).
-
 ### 3. Write tasks with verify commands
 
 Every task must have a `verify:` command. No verify command = not a task.
-
 ### 4. Save specs/release-plan.yaml
 
 > **Do NOT hand-track the real version.** semantic-release decides it at merge. `version` here is a
@@ -80,7 +76,6 @@ epics:
     wsjf: 3.8
     capsule_dir: epics/e02-user-profile
 ```
-
 ### 5. Save epic manifest (`epic.yaml`)
 
 Each epic capsule directory contains an `epic.yaml` manifest:
@@ -105,11 +100,9 @@ stories:
     spec: e01s02-jwt.md
     tasks: e01s02-tasks.yaml
 ```
-
 ### 6. Save story specs (countable-story-format .md)
 
 Each story becomes a standalone `.md` file following [countable-story-format.md](file:///Users/danielvm/Developer/bigpowers/countable-story-format.md). Minimum: maturity 3 (Countable) with all 20 sections present. Acceptance criteria in §17 use Gherkin scenarios.
-
 ### 7. Save decoupled task files (`-tasks.yaml`)
 
 Each story has a decoupled `-tasks.yaml` with implementation steps:
@@ -133,6 +126,9 @@ tasks:
 > **HARD GATE** — Every task MUST have a runnable `verify:` command. No `verify:` = not a task.
 
 → verify: `bash scripts/validate-specs-yaml.sh`
+### 7b. Generate bug registry summary
+
+Read `specs/bugs/registry.yaml` and add a `bugs:` section to `release-plan.yaml` with totals by status (`fixed`, `deferred`, `wontfix`, `open`): `bugs: { total: N, fixed: N, deferred: N, wontfix: N, registry: specs/bugs/registry.yaml }`.
 
 ### 8. Sync execution status
 
@@ -142,7 +138,6 @@ bash scripts/sync-status-from-epics.sh
 ### 9. Snapshot on planning close (optional)
 
 Copy to `specs/product/snapshots/release-<version>/` when the user approves the plan.
-
 ### 10. Suggest next steps
 
 - Run `assess-impact` before `plan-work` for any story touching existing modules.

package/.pi/skills/plan-work/SKILL.md

@@ -45,7 +45,7 @@ If this plan touches an existing module, run `assess-impact` first to understand
 
 2. **Draft steps** — Break implementation into the smallest possible steps where each step leaves the codebase working, has one observable outcome, and can be verified with a single command. Red-flag check: name any rationalization you caught before moving to step 3.
 
-3. **Write capsule story spec + tasks** — Output two files inside the active epic capsule. See [REFERENCE.md](REFERENCE.md) for file formats and the plan-template. Each task MUST include a `risk:` field (`P0` | `P1` | `P2` | `P3`) based on BCP + story type heuristics (see REFERENCE.md). If a test plan artifact (`specs/tech-architecture/eNN-TEST_PLAN_LATEST.md`) exists, read it and inherit its P0/P1 risk classifications and scenario IDs (`SC-eNNsYY-P0-NN`). Each task optionally includes a `security:` field (`none` / `low` / `medium` / `high`) sourced from the epic's `specs/security/epics/<id>/THREAT_MODEL.md`. Tasks with `security: medium` or `security: high` MUST include "no new security findings in affected paths" in their verify steps.
+3. **Write capsule story spec + tasks** — Output two files inside the active epic capsule. See [REFERENCE.md](REFERENCE.md) for file formats and the plan-template. Each task MUST include a `risk:` field (`P0` | `P1` | `P2` | `P3`) based on BCP + story type heuristics (see REFERENCE.md). If a test plan artifact (`specs/tech-architecture/eNN-TEST_PLAN_LATEST.md`) exists, read it and inherit its P0/P1 risk classifications and scenario IDs (`SC-eNNsYY-P0-NN`). Each task optionally includes a `security:` field (`none` / `low` / `medium` / `high`) sourced from the epic's `specs/security/epics/<id>/THREAT_MODEL.md`. Tasks with `security: medium` or `security: high` MUST include "no new security findings in affected paths" in their verify steps. Each task should also include an `allure:` block to drive test reporting: `severity:` maps risk to Allure severity (`P0→critical`, `P1→high`, `P2→normal`, `P3→minor`), and `categories:` is a list of relevant tags like `"Security Review"`, wave names, or test categories (see REFERENCE.md for the full template).
 
    **Requirement delta tags (e45s29):** When a story modifies existing behavior, the story spec § Requirements MUST use OpenSpec-style delta tags with mandatory before/after content:
 
@@ -133,8 +133,21 @@ tasks:
     verify: "npm test -- login-form.test.tsx"
     risk: P1
     status: failing   # flip to passing only after verify exits 0 (e45s06)
+    allure:
+      severity: high              # P0→critical, P1→high, P2→normal, P3→minor
+      categories:
+        - "Auth"
+        - "Security Review"
 ```
 
+**Allure severity mapping:**
+- `P0` → `critical`
+- `P1` → `high`
+- `P2` → `normal`
+- `P3` → `minor`
+
+`categories` is a list of relevant tags — wave names, test categories (e.g. `"unit"`, `"integration"`), or thematic groupings (e.g. `"Security Review"`).
+
 Update `specs/epics/<capsule>/epic.yaml` manifest to list the story and its BCPs. Run `bash scripts/sync-status-from-epics.sh` after structural changes.
 
 ## Plan template

package/CHANGELOG.md

@@ -1,3 +1,10 @@
+# [2.77.0](https://github.com/danielvm-git/bigpowers/compare/v2.76.3...v2.77.0) (2026-07-13)
+
+
+### Features
+
+* **e76:** enrich YAML metadata for Allure dashboards ([94c4417](https://github.com/danielvm-git/bigpowers/commit/94c4417cab844f86c794466ea38812b7e0b36a44))
+
 ## [2.76.3](https://github.com/danielvm-git/bigpowers/compare/v2.76.2...v2.76.3) (2026-07-11)
 
 

package/README.md

@@ -2,7 +2,7 @@
 
 ![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)
 ![npm version](https://img.shields.io/npm/v/bigpowers.svg)
-![Skills](https://img.shields.io/badge/skills-77-brightgreen.svg)
+![Skills](https://img.shields.io/badge/skills-79-brightgreen.svg)
 
 **Agent skills synthesizing 17 years of software engineering discipline — from Clean Code to AI-native architecture — into a single, prescriptive methodology for solo developers.**
 

package/SKILL-INDEX.md

@@ -3,7 +3,7 @@
 > **DO NOT EDIT** — This file is auto-generated by `scripts/generate-skill-index.sh`.
 > Edit `SKILL.md` source files or `skills-lock.json` instead. Run `bash scripts/sync-skills.sh` to regenerate.
 
-**Skills:** 77
+**Skills:** 79
 
 ---
 

package/allure-results/categories.json

@@ -0,0 +1,23 @@
+[
+  {
+    "name": "P0 Risk",
+    "matchedStatuses": [
+      "failed"
+    ],
+    "messageRegex": ".*risk.*P0.*"
+  },
+  {
+    "name": "Security Review",
+    "matchedStatuses": [
+      "failed"
+    ],
+    "messageRegex": ".*security.*(?:medium|high).*"
+  },
+  {
+    "name": "Open Bugs",
+    "matchedStatuses": [
+      "failed"
+    ],
+    "messageRegex": ".*Bug.*"
+  }
+]

package/allure-results/executor.json

@@ -0,0 +1,6 @@
+{
+  "name": "bigpowers",
+  "type": "bigpowers",
+  "buildName": "2.76.2",
+  "buildOrder": 328
+}