bigpowers 2.86.4 → 2.86.6

package/.pi/skills/harden-vps/SKILL.md

@@ -1,16 +1,16 @@
 ---
 name: harden-vps
 model: haiku
-description: "Harden a production Linux VPS for BigBase across three layers — BigBase app (systemd hardening, monitoring alerts, backup automation), Ubuntu OS (UFW firewall, fail2ban SSH, unattended-upgrades, SSH hardening), and Contabo VPS (health checks, daily backups, monthly snapshots). Use when the user wants to secure a production server, harden a VPS, audit server security, or mentions production hardening, VPS security, or harden the server."
+description: "Harden a production Linux VPS for your application across three layers — application (systemd hardening, monitoring alerts, backup automation), Ubuntu OS (UFW firewall, fail2ban SSH, unattended-upgrades, SSH hardening), and VPS provider (health checks, daily backups, monthly snapshots). Use when the user wants to secure a production server, harden a VPS, audit server security, or mentions production hardening, VPS security, or harden the server."
 ---
 
 # Harden VPS
 
-Three-layer production hardening for BigBase on Contabo VPS. Each layer independently verifiable. Apply OS first (firewall blocks attacks immediately), then BigBase (alerts + backups), then Contabo (snapshots). See [REFERENCE.md](../../../skills/harden-vps/REFERENCE.md) for full script bodies, systemd unit template, and gotchas.
+Three-layer production hardening for a self-hosted app on any VPS. Each layer independently verifiable. Apply OS first (firewall blocks attacks immediately), then your application (alerts + backups), then your VPS provider (snapshots). See [REFERENCE.md](../../../skills/harden-vps/REFERENCE.md) for full script bodies, systemd unit template, and gotchas.
 
 ## Quick start
 
-SSH as root into the VPS. Find credentials in the Contabo Customer Control Panel.
+SSH as root into the VPS. Find credentials in the your VPS provider Customer Control Panel.
 
 > **HARD GATE** — Run `ufw status` first. No firewall = layer 1 takes priority over everything.
 
@@ -35,21 +35,21 @@ apt install -y unattended-upgrades && dpkg-reconfigure -plow unattended-upgrades
 # SSH: PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes
 # → verify: sshd -T | grep -E 'permitrootlogin no|passwordauthentication no'
 
-# Deploy healthcheck.sh → /opt/bigbase/scripts/healthcheck.sh
-# Crontab: */5 * * * * /opt/bigbase/scripts/healthcheck.sh
+# Deploy healthcheck.sh → /opt/your-app/scripts/healthcheck.sh
+# Crontab: */5 * * * * /opt/your-app/scripts/healthcheck.sh
 ```
 
-## Layer 2 — BigBase application
+## Layer 2 — applicationlication
 
 ```bash
-# systemd: User=bigbase, NoNewPrivileges=yes, ProtectSystem=full,
+# systemd: User=your-app, NoNewPrivileges=yes, ProtectSystem=full,
 #   ProtectKernelTunables=yes, ProtectKernelModules=yes,
 #   ProtectControlGroups=yes, RestrictAddressFamilies=AF_INET AF_INET6,
 #   RestrictRealtime=yes, PrivateTmp=yes, LimitNOFILE=65536
-# → verify: systemctl show bigbase -p NoNewPrivileges -p ProtectSystem -p User
+# → verify: systemctl show your-app -p NoNewPrivileges -p ProtectSystem -p User
 
-# Alerts (BigBase requires auth; insert via SQLite)
-sqlite3 /opt/bigbase/data/bigbase.db "
+# Alerts (your application requires auth; insert via SQLite)
+sqlite3 /opt/your-app/data/your-app.db "
 INSERT INTO monitoring_alerts (id,name,metric,threshold,operator,enabled,duration_seconds)
 VALUES ('a1','Disk >80%','disk_used_percent',80,'gt',1,300);
 INSERT INTO monitoring_alerts (id,name,metric,threshold,operator,enabled,duration_seconds)
@@ -57,14 +57,14 @@ VALUES ('a2','CPU >90%','cpu_percent',90,'gt',1,60);
 INSERT INTO monitoring_alerts (id,name,metric,threshold,operator,enabled,duration_seconds)
 VALUES ('a3','RAM >85%','mem_used_percent',85,'gt',1,120);
 "
-systemctl restart bigbase
+systemctl restart your-app
 
 # Backup crontab (root):
-# 0 2 * * * cp /opt/bigbase/data/bigbase.db /backup/bigbase-$(date +\%Y\%m\%d).db
-# 0 3 * * * find /backup/ -name "bigbase-*.db" -mtime +90 -delete
+# 0 2 * * * cp /opt/your-app/data/your-app.db /backup/your-app-$(date +\%Y\%m\%d).db
+# 0 3 * * * find /backup/ -name "your-app-*.db" -mtime +90 -delete
 ```
 
-## Layer 3 — Contabo VPS
+## Layer 3 — VPS provider
 
 ```bash
 # cntb CLI
@@ -72,14 +72,14 @@ curl -sL "$(curl -sL https://api.github.com/repos/contabo/cntb/releases/latest \
   | grep browser_download_url.*linux_amd64.tar.gz | head -1 | cut -d'"' -f4)" \
   | tar xz -C /usr/local/bin
 
-# Snapshot script → /opt/bigbase/scripts/contabo-snapshot.sh (reads from /opt/bigbase/.env)
-# Credentials as env vars in /opt/bigbase/.env (deployed by GitHub Actions):
+# Snapshot script → /opt/your-app/scripts/contabo-snapshot.sh (reads from /opt/your-app/.env)
+# Credentials as env vars in /opt/your-app/.env (deployed by GitHub Actions):
 #   CONTABO_CLIENT_ID, CONTABO_CLIENT_SECRET, CONTABO_API_USER, CONTABO_API_PASSWORD
-# Crontab: 0 4 1 * * /opt/bigbase/scripts/contabo-snapshot.sh
+# Crontab: 0 4 1 * * /opt/your-app/scripts/contabo-snapshot.sh
 
 # > HARD GATE — Snapshot cron silently fails until env vars are set in .env.
-# Credentials source: Contabo Customer Panel → API Details.
-# Local dev: add to .envrc. Production: GitHub Secrets → deploy → /opt/bigbase/.env
+# Credentials source: your VPS provider Customer Panel → API Details.
+# Local dev: add to .envrc. Production: GitHub Secrets → deploy → /opt/your-app/.env
 ```
 
 ## CRITICAL GOTCHAS
@@ -87,7 +87,7 @@ curl -sL "$(curl -sL https://api.github.com/repos/contabo/cntb/releases/latest \
 1. **Shell escaping in Orca terminals:** `$VAR`, `$(…)`, and `%` get eaten by the local shell. Always use base64: `echo '<base64>' | base64 -d > script.sh`
 2. **Crontab `%`:** cron interprets `%` as newline. Escape as `\%` in `$(date +\%Y\%m\%d)`
 3. **fail2ban exit 255:** means a jail references a missing log file. Remove the broken jail, restart.
-4. **BigBase alerts need auth:** POST to `/api/monitoring/alerts` requires Bearer token. Workaround: insert directly into SQLite, then restart BigBase.
+4. **your application alerts need auth:** POST to `/api/monitoring/alerts` requires Bearer token. Workaround: insert directly into SQLite, then restart your application.
 
 ## Verify all 8 gates
 
@@ -96,10 +96,10 @@ ufw status|grep -q active||echo FAIL:ufw
 fail2ban-client status sshd>/dev/null 2>&1||echo FAIL:fail2ban
 systemctl is-active unattended-upgrades|grep -q active||echo FAIL:unattended
 sshd -T|grep -q 'permitrootlogin no'||echo FAIL:sshd
-systemctl show bigbase -p NoNewPrivileges|grep -q yes||echo FAIL:systemd
-systemctl is-active bigbase|grep -q active||echo FAIL:bigbase
-sqlite3 /opt/bigbase/data/bigbase.db "SELECT count(*) FROM monitoring_alerts"|grep -q 3||echo FAIL:alerts
-crontab -l|grep -q healthcheck&&crontab -l|grep -q bigbase.db&&crontab -l|grep -q contabo-snapshot||echo FAIL:crontab
+systemctl show your-app -p NoNewPrivileges|grep -q yes||echo FAIL:systemd
+systemctl is-active your-app|grep -q active||echo FAIL:your-app
+sqlite3 /opt/your-app/data/your-app.db "SELECT count(*) FROM monitoring_alerts"|grep -q 3||echo FAIL:alerts
+crontab -l|grep -q healthcheck&&crontab -l|grep -q your-app.db&&crontab -l|grep -q contabo-snapshot||echo FAIL:crontab
 echo ALL 8 GATES PASSED
 ```
 
@@ -111,47 +111,47 @@ echo ALL 8 GATES PASSED
 
 ## Health check script
 
-Deploy to `/opt/bigbase/scripts/healthcheck.sh`:
+Deploy to `/opt/your-app/scripts/healthcheck.sh`:
 
 ```bash
 #!/bin/bash
-LOG=/var/log/bigbase/health.log
-mkdir -p /var/log/bigbase
+LOG=/var/log/your-app/health.log
+mkdir -p /var/log/your-app
 DISK=$(df / | awk 'NR==2 {print $5}' | tr -d '%')
 RAM=$(free | awk '/Mem:/ {printf "%.0f", $3/$2*100}')
 NOW=$(date -Iseconds)
 [ "$DISK" -gt 85 ] && echo "$NOW ALERT: Disk ${DISK}%" >> "$LOG"
 [ "$RAM" -gt 90 ]   && echo "$NOW ALERT: RAM ${RAM}%" >> "$LOG"
-systemctl is-active --quiet bigbase || { echo "$NOW ALERT: BigBase DOWN" >> "$LOG"; systemctl restart bigbase; }
+systemctl is-active --quiet your-app || { echo "$NOW ALERT: your application DOWN" >> "$LOG"; systemctl restart your-app; }
 [ -f /var/run/reboot-required ] && echo "$NOW WARN: kernel reboot pending" >> "$LOG"
 ```
 
-Make executable: `chmod +x /opt/bigbase/scripts/healthcheck.sh`
+Make executable: `chmod +x /opt/your-app/scripts/healthcheck.sh`
 
-## BigBase systemd unit
+## your application systemd unit
 
-Full hardened unit at `/etc/systemd/system/bigbase.service`:
+Full hardened unit at `/etc/systemd/system/your-app.service`:
 
 ```ini
 [Unit]
-Description=BigBase BaaS Platform
-Documentation=https://github.com/danielvm-git/bigbase
+Description=your application BaaS Platform
+Documentation=https://github.com/example-org/example-app
 After=network.target caddy.service
 Wants=caddy.service
 
 [Service]
 Type=simple
-User=bigbase
-Group=bigbase
-WorkingDirectory=/opt/bigbase
-ExecStart=/opt/bigbase/bin/bigbase serve \
+User=your-app
+Group=your-app
+WorkingDirectory=/opt/your-app
+ExecStart=/opt/your-app/bin/your-app serve \
     --port 8080 \
-    --db /opt/bigbase/data/bigbase.db \
+    --db /opt/your-app/data/your-app.db \
     --sites-domain <your-domain.example.com>
-EnvironmentFile=-/opt/bigbase/.env
-Environment=BIGBASE_HOME=/opt/bigbase
-Environment=HOME=/opt/bigbase
-Environment=NPM_CONFIG_CACHE=/opt/bigbase/.npm
+EnvironmentFile=-/opt/your-app/.env
+Environment=APP_HOME=/opt/your-app
+Environment=HOME=/opt/your-app
+Environment=NPM_CONFIG_CACHE=/opt/your-app/.npm
 Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
 Restart=always
 RestartSec=5
@@ -168,11 +168,11 @@ ProtectKernelModules=yes
 ProtectControlGroups=yes
 RestrictAddressFamilies=AF_INET AF_INET6
 RestrictRealtime=yes
-ReadWritePaths=/opt/bigbase/data
-ReadWritePaths=/opt/bigbase/backups
-ReadWritePaths=/opt/bigbase/secrets
-ReadWritePaths=/opt/bigbase/.npm
-ReadWritePaths=/opt/bigbase/logs
+ReadWritePaths=/opt/your-app/data
+ReadWritePaths=/opt/your-app/backups
+ReadWritePaths=/opt/your-app/secrets
+ReadWritePaths=/opt/your-app/.npm
+ReadWritePaths=/opt/your-app/logs
 LimitNOFILE=65536
 
 [Install]
@@ -192,17 +192,20 @@ bantime = 3600
 findtime = 600
 ```
 
-Note: BigBase auth jail deferred — BigBase logs to journald, not a file. To enable, use `backend = systemd` with a journald filter.
+Note: your application auth jail deferred — your application logs to journald, not a file. To enable, use `backend = systemd` with a journald filter.
 
-## contabo-snapshot.sh
+## provider-snapshot.sh — worked example (Contabo API)
 
-Deploy to `/opt/bigbase/scripts/contabo-snapshot.sh`. Reads credentials from `/opt/bigbase/.env` (same file used by BigBase systemd unit):
+> Snapshot APIs are provider-specific. This is one worked example, not a
+> bigpowers default; swap the auth and endpoint calls for your own provider.
+
+Deploy to `/opt/your-app/scripts/contabo-snapshot.sh`. Reads credentials from `/opt/your-app/.env` (same file used by your application systemd unit):
 
 ```bash
 #!/bin/bash
 set -e
-LOG=/var/log/bigbase/snapshot.log
-ENVFILE=/opt/bigbase/.env
+LOG=/var/log/your-app/snapshot.log
+ENVFILE=/opt/your-app/.env
 INSTANCE_ID=<your-contabo-instance-id>
 
 [ -f "$ENVFILE" ] || { echo "$(date -Iseconds) ERROR: $ENVFILE missing" >> "$LOG"; exit 1; }
@@ -231,9 +234,9 @@ echo >> "$LOG"
 echo "$(date -Iseconds) Snapshot requested for $INSTANCE_ID" >> "$LOG"
 ```
 
-## Contabo credentials
+## your VPS provider credentials
 
-Add to `/opt/bigbase/.env` (same file used by BigBase systemd unit, deployed by GitHub Actions):
+Add to `/opt/your-app/.env` (same file used by your application systemd unit, deployed by GitHub Actions):
 
 ```
 CONTABO_CLIENT_ID=
@@ -242,13 +245,13 @@ CONTABO_API_USER=
 CONTABO_API_PASSWORD=
 ```
 
-Source: Contabo Customer Control Panel → API Details. ClientId and ClientSecret are generated there. API User is your email. API Password is set separately in the panel.
+Source: your VPS provider Customer Control Panel → API Details. ClientId and ClientSecret are generated there. API User is your email. API Password is set separately in the panel.
 
-**Pipeline:** GitHub Secrets → deploy workflow → `/opt/bigbase/.env` on VPS. For local dev (`cntb get instances`), add to `.envrc`.
+**Pipeline:** GitHub Secrets → deploy workflow → `/opt/your-app/.env` on VPS. For local dev (`cntb get instances`), add to `.envrc`.
 
-## Contabo instance info template
+## your VPS provider instance info template
 
-Fill in your instance details from the Contabo Customer Control Panel:
+Fill in your instance details from the your VPS provider Customer Control Panel:
 
 ```
 IP:           <your-instance-ip>
@@ -260,7 +263,7 @@ Default user: root
 Customer ID:  <your-customer-id>
 ```
 
-## BigBase monitoring alert SQL
+## your application monitoring alert SQL
 
 ```sql
 INSERT INTO monitoring_alerts (id, name, metric, threshold, operator, enabled, duration_seconds)
@@ -273,7 +276,7 @@ INSERT INTO monitoring_alerts (id, name, metric, threshold, operator, enabled, d
 VALUES ('alert-003', 'VPS RAM above 85%', 'mem_used_percent', 85, 'gt', 1, 120);
 ```
 
-Alerts are loaded at BigBase startup. Restart with `systemctl restart bigbase` after inserting.
+Alerts are loaded at your application startup. Restart with `systemctl restart your-app` after inserting.
 
 ## Base64 encoding workaround
 

package/.pi/skills/investigate-bug/SKILL.md

@@ -123,5 +123,5 @@ After writing the bug file, print a one-line summary of the root cause and sugge
 
 <!-- story: e35s10 -->
 
-- [Feathers' Seams & Characterization Tests](https://github.com/danielvm-git/bigpowers/blob/main/docs/references/feathers.md) — seam types, characterization tests, and the legacy code change algorithm
-- [Fowler's Code Smells](https://github.com/danielvm-git/bigpowers/blob/main/docs/references/fowler.md) — identifying structural problems by smell before investigating
+- [Feathers' Seams & Characterization Tests](../../../docs/references/feathers.md) — seam types, characterization tests, and the legacy code change algorithm
+- [Fowler's Code Smells](../../../docs/references/fowler.md) — identifying structural problems by smell before investigating

package/.pi/skills/orchestrate-project/SKILL.md

@@ -94,7 +94,7 @@ Detailed documentation for the `orchestrate-project` meta-skill.
 ### PHASE 3: PLAN
 - **Goal**: Write a verifiable implementation plan with success criteria.
 - **Deliverables**: `release-plan.yaml`, `epics/eNN-*.yaml` with `verify:` per task.
-- **Skills**: `scope-work`, `slice-tasks`, `define-success`, `plan-work`.
+- **Skills**: `scope-work`, `slice-tasks`, `plan-work`.
 - **Gate**: Quality (request-review ≥94%) + slopcheck [SUS]/[SLOP].
 
 ### PHASE 4: BUILD

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

@@ -81,7 +81,7 @@ After writing `specs/REFACTOR_LATEST.md`, suggest running `kickoff-branch` next
 
 <!-- story: e35s10 -->
 
-- [Fowler's Refactoring Catalog](https://github.com/danielvm-git/bigpowers/blob/main/docs/references/fowler.md) — canonical refactoring vocabulary and code-smell taxonomy
-- [Beck's Tidy First?](https://github.com/danielvm-git/bigpowers/blob/main/docs/references/kent-beck.md) — structural change before behavioral change
+- [Fowler's Refactoring Catalog](../../../docs/references/fowler.md) — canonical refactoring vocabulary and code-smell taxonomy
+- [Beck's Tidy First?](../../../docs/references/kent-beck.md) — structural change before behavioral change
 
 ## Verify

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

@@ -17,7 +17,7 @@ Synthesize the conversation context into `specs/release-plan.yaml` (index) and s
 |------|---------|
 | `specs/release-plan.yaml` | `release.version`, semver bump hint, WSJF-ordered epic list with `id`, `capsule_dir`, `wsjf`, `bcps` — **no story status** |
 | `specs/epics/eNN-<slug>/epic.yaml` | Epic manifest: `id`, `title`, `wsjf`, `total_bcps`, `status`, `stories[]` list |
-| `specs/epics/eNN-<slug>/eNNsYY-<slug>.md` | Story spec in [countable-story-format.md](https://github.com/danielvm-git/bigpowers/blob/main/docs/countable-story-format.md) with 20 sections and Gherkin acceptance criteria |
+| `specs/epics/eNN-<slug>/eNNsYY-<slug>.md` | Story spec in [countable-story-format.md](../../../docs/countable-story-format.md) with 20 sections and Gherkin acceptance criteria |
 | `specs/epics/eNN-<slug>/eNNsYY-tasks.yaml` | Decoupled task checklist with `verify:` commands per task |
 | `specs/execution-status.yaml` | Flat key-value store for story status (`eNNsYY: todo`) |
 
@@ -102,7 +102,7 @@ stories:
 ```
 ### 6. Save story specs (countable-story-format .md)
 
-Each story becomes a standalone `.md` file following [countable-story-format.md](https://github.com/danielvm-git/bigpowers/blob/main/docs/countable-story-format.md). Minimum: maturity 3 (Countable) with all 20 sections present. Acceptance criteria in §17 use Gherkin scenarios.
+Each story becomes a standalone `.md` file following [countable-story-format.md](../../../docs/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:

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

@@ -12,7 +12,7 @@ description: "PLANNING SPINE STEP 3 of 3 — Plan the work: write detailed imple
 
 Produce a detailed, verifiable implementation plan in the **active epic capsule directory** (`specs/epics/eNN-slug/`). Output: a story spec `.md` file (countable-story-format) and a decoupled `eNNsYY-tasks.yaml` with runnable verify commands. "I think it works" is not a step.
 
-> **HARD GATE** — Do NOT proceed with a plan until the task's success criteria are clear. If success is ambiguous, run `define-success` first to convert the task into "step → verify: <cmd>" pairs.
+> **HARD GATE** — Do NOT proceed with a plan until the task's success criteria are clear. If success is ambiguous, convert the task into "step → verify: `<cmd>`" pairs here before writing tasks — every task ships a runnable `verify:` or the plan is not done.
 >
 > **RECURSIVE DISCIPLINE** — This lifecycle applies to EVERY task, including updating these skills. Never skip planning because a task is "meta" or "just documentation."
 

package/.pi/skills/using-bigpowers/SKILL.md

@@ -8,7 +8,7 @@ description: "One-time bootstrap that introduces the bigpowers skills system, th
 > **HARD GATE** — **HARD GATE** — This skill is the entry point. Do NOT skip it when onboarding new users or starting a new session. It establishes the bigpowers methodology, lifecycle phases, and conventions.
 
 
-Welcome to **bigpowers** — a lifecycle of **70** agent skills for production-ready, TDD-driven software by solo developers.
+Welcome to **bigpowers** — a lifecycle of agent skills for production-ready, TDD-driven software by solo developers. The live catalog and its count are generated in [                ](../../../SKILL-INDEX.md); never hardcode the number here.
 
 ## Install
 
@@ -37,7 +37,7 @@ DISCOVER    survey-context → research-first → elaborate-spec
               ↓
 DESIGN      model-domain / define-language / grill-me / deepen-architecture / design-interface
               ↓
-PLAN        scope-work → slice-tasks → define-success → plan-work / plan-refactor
+PLAN        scope-work → slice-tasks → plan-work / plan-refactor
               ↓
 INITIATE    kickoff-branch → guard-git / hook-commits / seed-conventions
               ↓

package/.pi/skills/wire-ci/SKILL.md

@@ -258,7 +258,7 @@ jobs:
 
 ---
 
-## Reference block 2 — deploy.yml (BigBase, excerpt)
+## Reference block 2 — deploy.yml (generic web app, excerpt)
 
 ```yaml
 name: Deploy
@@ -276,7 +276,7 @@ concurrency:
   cancel-in-progress: false
 
 env:
-  SITE_URL: "https://CHANGE-ME.bigbase.click"
+  SITE_URL: "https://CHANGE-ME.example.com"
 
 jobs:
   deploy:
@@ -292,18 +292,15 @@ jobs:
           github-token: ${{ secrets.GITHUB_TOKEN }}
           run-id: ${{ github.event.workflow_run.id }}
           path: deploy-meta
-      # BigBase-specific composite action, not a bigpowers default: this deploy
-      # example targets the author's own hosting stack. Replace it with your
-      # platform's deploy step (or drop the deploy job entirely for CLI and
-      # library repos). bigpowers itself ships no deploy templates. (GH #104)
-      - uses: danielvm-git/.github/actions/bigbase-deploy@9c56ac10c629f3baa110ddb19136579e3c90d690  # v1
-        with:
-          site_id: ${{ secrets.BIGBASE_SITE_ID }}
-          app_type: go
-          site_url: ${{ env.SITE_URL }}
-          deploy_token: ${{ secrets.BIGBASE_DEPLOY_TOKEN }}
-          ref: ${{ steps.meta.outputs.ref }}
-          skip_health_check: true
+      # Placeholder deploy step — bigpowers ships no deploy templates and pins
+      # no third-party action. Substitute your platform's own step here, or drop
+      # the deploy job entirely for CLI and library repos. Pin whatever action
+      # you choose to a full commit SHA rather than a tag. (GH #104)
+      - name: Deploy
+        run: |
+          echo "Replace this step with your platform's deploy command."
+          echo "commit=$(jq -r .sha deploy-meta/deploy-meta.json)"
+          exit 1
       - name: Health check
         run: |
           curl -sf "${{ env.SITE_URL }}" || exit 1

package/.pi/skills/write-document/SKILL.md

@@ -247,7 +247,7 @@ Detect from CLAUDE.md or project LICENSE file.
 ```markdown
 ## Credits
 
-Built with [bigpowers](https://github.com/danielvm-git/bigpowers).
+Built with [bigpowers](https://www.npmjs.com/package/bigpowers).
 ```
 
 ## Verify

package/.qwen/skills/align-grid/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: align-grid
+model: sonnet
+description: "Build editorial/magazine/report webpages on a GENUINE Müller-Brockmann modular grid (International Typographic Style) — not a decorative one. Encodes the discipline (columns + modules + baseline, grotesque type, flush-left, restrained black/white/red palette) AND the hard-won front-end engineering to make the grid real, visible, and verified: one CSS-variable source of truth, an interactive grid-toggle overlay that lives in the SAME content box as the content, subgrid \"bands\" so every element snaps to a column line, an 8px baseline lock, and runtime OPTICAL ALIGNMENT that puts display type's ink (not its box) on the line. Ships with a scaffold generator and a Puppeteer verification harness that proves 0px adherence."
+---
+
+# Müller-Brockmann Grid Systems — built real, visible, and verified
+
+Josef Müller-Brockmann (1914–1996), Zurich; *Grid Systems in Graphic Design* (1981) is the corpus. The grid is treated as an ethic, not decoration: **"The grid system is an aid, not a guarantee. It permits a number of possible uses and each designer can look for a solution appropriate to his personal style. But one must learn how to use the grid; it is an art that requires practice."** This skill encodes that discipline AND — the part most attempts get wrong — the front-end engineering to make the grid genuinely load-bearing on the web, plus a harness that PROVES it.
+
+> **HARD GATE** — Do NOT ship a grid page without running `verify_grid.js` first. A visually plausible layout is not evidence of grid adherence — the harness is. Zero failing assertions is the only passing bar.
+
+> Two real review notes this skill exists to prevent:
+> 1. *"the grid is just slapped on top and misaligned"* → the overlay wasn't in the same content box as the content (see §2.2).
+> 2. *"the H in the headline is off the grid"* → the headline's BOX was on the grid but its INK wasn't; large glyphs carry a side-bearing (see §2.6). **Box-on-grid ≠ ink-on-grid.**
+
+---
+
+## PART 1 — THE DISCIPLINE (decide before drawing)
+- **Objective order.** The grid brings "constructive thought," legibility, and "objective and functional" design. Restraint is the point; the system, not the ego, organizes the page.
+- **Modular grid.** Divide the type area into a field of **modules** — columns AND rows — separated by consistent **gutters**, inside defined **margins**. Text and images occupy whole modules. Müller-Brockmann specimens common field counts (8 / 20 / 32 fields). For the web, a **12-column grid + 8px baseline** is a robust general default; a **6×6 or 4×8 modular field grid** when you want visible rows too.
+- **Baseline grid.** Vertical rhythm is sacred: **leading = a whole multiple of the baseline unit**, and every element snaps to it. This is what makes facing columns and images line up across the page.
+- **Typography.** A **grotesque sans** (Akzidenz-Grotesk / Helvetica; on the web Inter, Helvetica Now, Archivo). **Flush-left, ragged-right.** Few sizes, large jumps in **scale** for hierarchy; objective, not expressive. Big **numerals/data set large** is a signature move.
+- **Palette.** Pure white paper, near-black ink, **one accent — red is canonical**. Avoid the warm-cream "Claude look"; **never blue/purple gradients** (hard house rule).
+- **White space + asymmetry.** Generous margins; asymmetric compositions held in tension by the grid.
+
+---
+
+## PART 2 — MAKE THE GRID REAL ON THE WEB (the load-bearing engineering)
+`grid_tokens.py` emits this whole scaffold correctly; the rules below are why it's built the way it is.
+
+### 2.1 One source of truth
+Put every grid parameter in `:root` CSS variables — `--cols, --gutter, --margin, --bl (baseline), --lh (leading=3×bl), --maxw`. **Content and the overlay both read these same variables.** Never hand-author the overlay separately or it will drift.
+
+### 2.2 The overlay MUST live in the SAME content box as the content  ← #1 bug
+Failure mode: content sits in a centered `max-width` container while the overlay is a **full-width sibling** of the section. On any viewport wider than `--maxw`, the centered content and the full-width overlay no longer share column positions → "slapped on top / misaligned."
+**Fix:** put `.guides` *inside* the same `.wrap`, and draw the column guides with `left/right = var(--margin)` and the **same** `repeat(var(--cols),1fr)` + `column-gap:var(--gutter)`. Then the overlay columns **are** the content columns at every width. Add left/right margin lines at `var(--margin)`.
+
+### 2.3 Place every element by column LINE via subgrid bands
+Don't eyeball spans. Each horizontal **band** spans all columns and re-exposes them:
+```css
+.band{grid-column:1 / -1; display:grid; grid-template-columns:subgrid; column-gap:var(--gutter); align-items:start;}
+@supports not (grid-template-columns:subgrid){ .band{grid-template-columns:repeat(var(--cols),1fr);} }
+```
+Children place with `grid-column: <startline> / <endline>` (e.g. `1 / 6`, `6 / 13`). Every headline, paragraph, photo, caption now snaps to identical lines.
+
+### 2.4 Lock vertical rhythm to the baseline
+- Leading = `--lh` (e.g. 24px = 3×8). **Every line-height a multiple of the baseline, in px (not unitless) for display type** — unitless line-heights on large type push the box off the grid.
+- Every margin/padding a multiple of the baseline. Spread top/bottom padding a multiple too, so content starts on a line.
+- **Media heights = multiples of the leading** (e.g. 240/360/432/480px) so a photo's top AND bottom both land on lines.
+- Hairline rules sit inside a baseline-height band, not free-floating.
+
+### 2.5 The toggle (sizzle within the sizzle)
+A control (button **+ `G` key**) toggles `body.grid-on`; overlay fades 0→1. Overlay draws: translucent **numbered column fields**, the **baseline** (major line every `--lh`, faint minor every `--bl`), and **margin lines**. Showing the real grid the page is built on IS the demo.
+
+### 2.6 OPTICAL ALIGNMENT — display ink, not its box  ← the subtle bug
+A 180px headline whose layout box is exactly on line 1 still looks misaligned against body text, because the letterform's **ink** is inset by its **left side-bearing**. Cure at runtime:
+```js
+// after document.fonts.ready and on resize:
+var cvs=document.createElement('canvas'),ctx=cvs.getContext('2d');
+document.querySelectorAll('.masthead,.numeral,.shead h2,.h2b').forEach(function(el){
+  el.style.marginLeft='0px';
+  var cs=getComputedStyle(el),ch=(el.textContent||'').trim()[0]; if(!ch) return;
+  if(cs.textTransform==='uppercase') ch=ch.toUpperCase();
+  ctx.font=cs.fontStyle+' '+cs.fontWeight+' '+cs.fontSize+' '+cs.fontFamily; ctx.textAlign='left';
+  var abl=ctx.measureText(ch).actualBoundingBoxLeft;     // +ve = ink overhangs left of box
+  if(isFinite(abl)) el.style.marginLeft=abl.toFixed(2)+'px'; // shift box so INK lands on the line
+});
+```
+Apply to the masthead, big numerals, and section headlines. It scales with fluid type (re-runs on resize) and uses the **actually-loaded** font, so it's correct in the user's browser.
+**CRITICAL measurement caveat:** side-bearing is **font-specific**. If you measure with the wrong font you get the wrong nudge. Headless/sandbox Chrome usually lacks the webfont, so canvas falls back to a different grotesque (measured **−16px on the fallback vs −7px on real Inter** for the same `H`). To verify optics offline you must **embed the real webfont** via `@font-face` (local TTF). In production the runtime JS measures the loaded font and is correct.
+
+---
+
+## PART 3 — VERIFY (don't trust, measure)  → `verify_grid.js`
+Render with headless Chrome (Puppeteer) and assert, at **several widths including > and < `--maxw`** (to catch centered-container drift, e.g. 1440 / 1180 / 900):
+1. **Column adherence** — every placed `.band > *` left snaps to a column START and right to a column END (~0px). **Exclude the optically-aligned display elements** from this box check (their box is intentionally side-bearing-offset; they're validated in step 4). **Gotcha:** build BOTH the column-start set and the column-end set — a grid item spanning "to line N" ends at the *far* side of the gutter, so single-edge math falsely reports a one-gutter error.
+2. **Overlay match** — each `.guides .col` rect equals the computed column rect (~0px).
+3. **Baseline** — text tops modulo the baseline ≈ 0 (tolerance ≈ half a baseline; the box-top is a proxy — the leading does the real work).
+4. **Optical ink** — each display element's ink-left (box − `actualBoundingBoxLeft`, real font) equals **its own** column line (nearest column-start to its box), not always line 1.
+
+Sandbox Chrome flags that work: `--headless=new --no-sandbox --disable-gpu --disable-dbus --use-gl=angle --use-angle=swiftshader`. `file://` works for non-ES-module pages; the CLI `--screenshot` can hang on tall pages — drive via Puppeteer and screenshot per viewport. Read PNGs back with the image-capable Read tool to eyeball a **zoom crop of the top-left corner** (masthead vs body vs column line) — the fastest human check.
+
+A clean run looks like: `col=0px overlay=0px baseline≤4px ink=0px` → `GRID VERIFY: PASS`.
+
+---
+
+## PART 4 — CRAFT DEFAULTS (so it looks excellent, not just aligned)
+- **Palette:** white `#fff`, ink `#111`, one accent (Swiss red `#e4002b`). No warm-cream Claude look; no blue/purple gradients.
+- **Type:** a real grotesque webfont (Inter / Helvetica Now / Archivo) for display + body; a **mono** (Space Mono / IBM Plex Mono) for folios, captions, grid annotations — reinforces the technical register. Non-Latin via Noto Sans JP etc.
+- **Hierarchy** through scale + weight + white space, not color. Treat key data as **large numerals**. Kicker labels in mono caps. Per-spread folios.
+- **Real photography.** Ground real subjects in real photos (`SearchImages`). **Host each image via `PublishFilePublicly` and embed the `pub.hyperagent.com` URL** — a `PublishWebpage` artifact runs in a sandboxed iframe that can't authenticate thread-scoped `/api/files/...` URLs (broken-image trap).
+- **Type fidelity if you ever rasterize art** (cairosvg / headless screenshots / image-gen reference): a `Helvetica`/`Arial` CSS stack silently falls back to **Noto Sans** (reads like Calibri). Render in **Liberation Sans** or an embedded Helvetica/Arimo TTF before trusting it. (Same trap as the optical-measurement caveat: wrong font in → wrong result out.)
+- **Spread model:** full-width sections, each its own per-spread `.grid` + `.guides`, consistent margins/folios.
+
+---
+
+## PART 5 — WORKFLOW
+1. Pick the subject; gather real photos; host them publicly.
+2. Generate the scaffold: `python3 grid_tokens.py` (or `--scaffold` for a full page; `--cols/--baseline/--gutter/--margin/--maxw/--accent` to taste; it warns if gutter/margin aren't baseline multiples).
+3. Build spreads as **subgrid bands**; place everything by **column line**; lock spacing/line-heights/media heights to the **baseline**.
+4. Add the overlay (same content box) + toggle + optical-alignment JS (already in the scaffold; point its selector list at your display elements).
+5. Publish, then **verify**: `CHROME=… PUP=… node verify_grid.js <file-or-url> --widths=1440,1180,900`. Eyeball a top-left zoom crop. Fix, republish.
+
+## SCRIPTS
+- **`grid_tokens.py`** — deterministic scaffold generator. Emits the `:root` tokens, `.grid`/`.band` (subgrid) scaffold, `.guides` overlay CSS, toggle JS, and the optical-alignment JS — all wired to one source of truth. `--scaffold` emits a full minimal HTML page. No network/credentials.
+- **`verify_grid.js`** — Puppeteer harness implementing all four checks above with the corrected both-edges column math, the optical-exclusion, per-element column-line ink targeting, and PASS/FAIL output at multiple widths. Env: `CHROME` (chrome binary), `PUP` (puppeteer-core module path).
+
+## CREED
+A grid you can't toggle on and measure is a mood board, not a system. Build it from one source of truth, prove it at 0px, and align the **ink**.

package/.qwen/skills/assess-impact/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: assess-impact
+model: sonnet
+description: "Analyze the blast radius of a proposed change before any code is written. Maps dependents, affected stories, and test coverage. Produces specs/IMPACT_LATEST.md. Use before plan-work on any non-trivial change, when touching a shared module, or when the user asks \"what does this break?\"."
+---
+
+# Assess Impact
+
+> **HARD GATE** — Run this skill before `plan-work` whenever a change touches an existing module, symbol, or file used by more than one caller. Skip only for net-new code with no existing dependents.
+
+Find the blast radius of the proposed change before a single line is written.
+
+## Modes
+
+- Default: full impact analysis (dependents + affected stories + test coverage mapping)
+- --lightweight: Fast fan-in/fan-out only (<10s). Maps callers and imports without test coverage mapping. Used by build-epic step 2 as a pre-plan gate. Risk score > 7 triggers a mandatory grill-me session before proceeding.
+
+## Process
+
+### 1. Identify the target
+
+Name the symbol, module, or file being changed. If the user hasn't specified, ask one question: "What exactly are you changing?"
+
+### 2. Find dependents
+
+```
+grep -rn "[symbol-name]" . --include="*.ts" | grep -v node_modules
+git log --oneline -10 -- [file-path]
+```
+
+→ verify: `test -f specs/IMPACT_LATEST.md || test -d specs/bugs`
+
+### 3. Map to release plan stories
+
+Read `specs/release-plan.yaml + epic capsule directories` (if it exists). For each dependent found in Step 2, identify which story owns that module. List stories that will be affected by the change.
+
+→ verify: `test -f specs/release-plan.yaml && grep -ci "stor" specs/release-plan.yaml`
+
+### 4. List test coverage
+
+Find tests that exercise the target:
+
+```
+grep -rn "[symbol-name]" . --include="*.test.*" --include="*.spec.*"
+```
+
+→ verify: `test -d specs/epics || test -d skills`
+
+### 5. Classify risk
+
+| Level | Condition |
+|-------|-----------|
+| Low   | ≤ 2 callers, all covered by tests |
+| Medium | 3–10 callers, partial test coverage |
+| High  | > 10 callers, or shared API/interface, or no tests |
+
+### 6. Write specs/IMPACT_LATEST.md
+
+```
+## Target
+[symbol or file being changed]
+
+## Dependents ([count])
+- [file]: [caller or usage]
+
+## Affected Stories
+- Story [X.Y]: [title]
+
+## Test Coverage
+- [test file]: covers [scenario]
+- Gap: [untested behavior]
+
+## Risk: Low / Medium / High
+[One-sentence rationale]
+
+## Recommended action
+[Proceed / Add tests first / Discuss design]
+```
+
+→ verify: `grep "Risk:" specs/IMPACT_LATEST.md`
+
+Suggest `plan-work` once risk is understood and any test gaps are noted.
+
+## Risk score gating
+
+In `--lightweight` mode (used by build-epic step 2), assign a numeric risk score (1–10):
+- Fan-in (how many callers): 0–4 points
+- Fan-out (how many dependencies the module itself uses): 0–3 points  
+- Recent churn (git log --oneline -5 count): 0–3 points
+
+**Risk score > 7**: Gate — require a `grill-me` session before proceeding to implementation. Document the grill-me result in the impact report at `specs/IMPACT-<epic>-<story>.md`.