bigpowers 2.76.3 → 2.77.1

package/skills/guard-git/SKILL.md

@@ -22,7 +22,7 @@ Installs a shared hook that blocks destructive git operations and enforces workf
 ## Quick start
 
 1. **Scope**: ask project-only vs global (paths differ per product).
-2. **Copy the hook bundle** from the root [hooks/](hooks/) directory to the client's hooks directory.
+2. **Write the hook bundle** from [REFERENCE.md](REFERENCE.md) into the client's hooks directory.
 3. **Run `chmod +x`** on `pre-tool-use.sh`.
 4. **Merge** the hook snippet from [REFERENCE.md](REFERENCE.md) into the right settings file — do not wipe unrelated keys.
 5. **Verify** with the tests in [REFERENCE.md](REFERENCE.md).

package/skills/harden-vps/REFERENCE.md

@@ -0,0 +1,179 @@
+# Harden VPS — Reference
+
+## Health check script
+
+Deploy to `/opt/bigbase/scripts/healthcheck.sh`:
+
+```bash
+#!/bin/bash
+LOG=/var/log/bigbase/health.log
+mkdir -p /var/log/bigbase
+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; }
+[ -f /var/run/reboot-required ] && echo "$NOW WARN: kernel reboot pending" >> "$LOG"
+```
+
+Make executable: `chmod +x /opt/bigbase/scripts/healthcheck.sh`
+
+## BigBase systemd unit
+
+Full hardened unit at `/etc/systemd/system/bigbase.service`:
+
+```ini
+[Unit]
+Description=BigBase BaaS Platform
+Documentation=https://github.com/danielvm-git/bigbase
+After=network.target caddy.service
+Wants=caddy.service
+
+[Service]
+Type=simple
+User=bigbase
+Group=bigbase
+WorkingDirectory=/opt/bigbase
+ExecStart=/opt/bigbase/bin/bigbase serve \
+    --port 8080 \
+    --db /opt/bigbase/data/bigbase.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
+Environment=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+Restart=always
+RestartSec=5
+StartLimitIntervalSec=60
+StartLimitBurst=3
+TimeoutStopSec=30
+KillSignal=SIGTERM
+NoNewPrivileges=yes
+PrivateTmp=yes
+ProtectSystem=full
+ProtectHome=yes
+ProtectKernelTunables=yes
+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
+LimitNOFILE=65536
+
+[Install]
+WantedBy=multi-user.target
+```
+
+## fail2ban jail.local
+
+```ini
+[sshd]
+enabled = true
+port = ssh
+filter = sshd
+logpath = /var/log/auth.log
+maxretry = 3
+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.
+
+## contabo-snapshot.sh
+
+Deploy to `/opt/bigbase/scripts/contabo-snapshot.sh`. Reads credentials from `/opt/bigbase/.env` (same file used by BigBase systemd unit):
+
+```bash
+#!/bin/bash
+set -e
+LOG=/var/log/bigbase/snapshot.log
+ENVFILE=/opt/bigbase/.env
+INSTANCE_ID=<your-contabo-instance-id>
+
+[ -f "$ENVFILE" ] || { echo "$(date -Iseconds) ERROR: $ENVFILE missing" >> "$LOG"; exit 1; }
+set -a; source "$ENVFILE"; set +a
+
+[ -z "$CONTABO_CLIENT_ID" ] && { echo "$(date -Iseconds) ERROR: CONTABO_CLIENT_ID not set" >> "$LOG"; exit 1; }
+
+TOKEN=$(curl -s -d "client_id=$CONTABO_CLIENT_ID" \
+  -d "client_secret=$CONTABO_CLIENT_SECRET" \
+  --data-urlencode "username=$CONTABO_API_USER" \
+  --data-urlencode "password=$CONTABO_API_PASSWORD" \
+  -d 'grant_type=password' \
+  'https://auth.contabo.com/auth/realms/contabo/protocol/openid-connect/token' \
+  | jq -r '.access_token')
+
+[ -z "$TOKEN" ] || [ "$TOKEN" = "null" ] && { echo "$(date -Iseconds) ERROR: auth failed" >> "$LOG"; exit 1; }
+
+curl -s -X POST \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -H "x-request-id: $(uuidgen 2>/dev/null || echo $RANDOM)" \
+  "https://api.contabo.com/v1/compute/instances/${INSTANCE_ID}/snapshots" \
+  | tee -a "$LOG"
+
+echo >> "$LOG"
+echo "$(date -Iseconds) Snapshot requested for $INSTANCE_ID" >> "$LOG"
+```
+
+## Contabo credentials
+
+Add to `/opt/bigbase/.env` (same file used by BigBase systemd unit, deployed by GitHub Actions):
+
+```
+CONTABO_CLIENT_ID=
+CONTABO_CLIENT_SECRET=
+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.
+
+**Pipeline:** GitHub Secrets → deploy workflow → `/opt/bigbase/.env` on VPS. For local dev (`cntb get instances`), add to `.envrc`.
+
+## Contabo instance info template
+
+Fill in your instance details from the Contabo Customer Control Panel:
+
+```
+IP:           <your-instance-ip>
+IPv6:         <your-instance-ipv6>
+Region:       <your-region>
+OS:           <your-os-version>
+Disk:         <your-disk-size>
+Default user: root
+Customer ID:  <your-customer-id>
+```
+
+## BigBase monitoring alert SQL
+
+```sql
+INSERT INTO monitoring_alerts (id, name, metric, threshold, operator, enabled, duration_seconds)
+VALUES ('alert-001', 'VPS Disk above 80%', 'disk_used_percent', 80, 'gt', 1, 300);
+
+INSERT INTO monitoring_alerts (id, name, metric, threshold, operator, enabled, duration_seconds)
+VALUES ('alert-002', 'VPS CPU above 90%', 'cpu_percent', 90, 'gt', 1, 60);
+
+INSERT INTO monitoring_alerts (id, name, metric, threshold, operator, enabled, duration_seconds)
+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.
+
+## Base64 encoding workaround
+
+When sending scripts through Orca terminal `--text`, the local bash shell interprets `$`, `(`, and `%`. Encode locally and decode remotely:
+
+```bash
+# Local
+cat script.sh | base64
+
+# Remote terminal
+echo '<base64-output>' | base64 -d > script.sh
+```

package/skills/harden-vps/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: harden-vps
+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."
+model: haiku
+effort: standard
+---
+
+# 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](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.
+
+> **HARD GATE** — Run `ufw status` first. No firewall = layer 1 takes priority over everything.
+
+## Layer 1 — Ubuntu OS
+
+```bash
+# UFW
+ufw default deny incoming && ufw default allow outgoing
+ufw allow 22/tcp && ufw allow 80/tcp && ufw allow 443/tcp && ufw enable
+# → verify: ufw status | grep -q active
+
+# fail2ban
+apt install -y fail2ban
+# Configure /etc/fail2ban/jail.local: sshd, maxretry=3, bantime=3600, findtime=600
+systemctl restart fail2ban
+# → verify: fail2ban-client status sshd
+
+# unattended-upgrades
+apt install -y unattended-upgrades && dpkg-reconfigure -plow unattended-upgrades
+# → verify: systemctl is-active unattended-upgrades | grep -q active
+
+# 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
+```
+
+## Layer 2 — BigBase application
+
+```bash
+# systemd: User=bigbase, 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
+
+# Alerts (BigBase requires auth; insert via SQLite)
+sqlite3 /opt/bigbase/data/bigbase.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)
+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
+
+# 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
+```
+
+## Layer 3 — Contabo VPS
+
+```bash
+# cntb CLI
+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):
+#   CONTABO_CLIENT_ID, CONTABO_CLIENT_SECRET, CONTABO_API_USER, CONTABO_API_PASSWORD
+# Crontab: 0 4 1 * * /opt/bigbase/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
+```
+
+## CRITICAL GOTCHAS
+
+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.
+
+## Verify all 8 gates
+
+```bash
+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
+echo ALL 8 GATES PASSED
+```
+
+→ verify: run the 8-gate one-liner on the VPS.

package/skills/investigate-bug/SKILL.md

@@ -124,6 +124,6 @@ After writing the bug file, print a one-line summary of the root cause and sugge
 
 <!-- story: e35s10 -->
 
-- [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
+- [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
 

package/skills/model-domain/CONTEXT-FORMAT.md

@@ -57,9 +57,9 @@ _Avoid_: Client, buyer, account
 
 ## Contexts
 
-- [Ordering](./src/ordering/CONTEXT.md) — receives and tracks customer orders
-- [Billing](./src/billing/CONTEXT.md) — generates invoices and processes payments
-- [Fulfillment](./src/fulfillment/CONTEXT.md) — manages warehouse picking and shipping
+- Ordering — `src/ordering/CONTEXT.md` — receives and tracks customer orders
+- Billing — `src/billing/CONTEXT.md` — generates invoices and processes payments
+- Fulfillment — `src/fulfillment/CONTEXT.md` — manages warehouse picking and shipping
 
 ## Relationships
 

package/skills/plan-refactor/SKILL.md

@@ -82,8 +82,8 @@ After writing `specs/REFACTOR_LATEST.md`, suggest running `kickoff-branch` next
 
 <!-- story: e35s10 -->
 
-- [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
+- [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
 
 ## Verify
 

package/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](file:///Users/danielvm/Developer/bigpowers/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](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-tasks.yaml` | Decoupled task checklist with `verify:` commands per task |
 | `specs/execution-status.yaml` | Flat key-value store for story status (`eNNsYY: todo`) |
 
@@ -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.
-
+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.
 ### 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/skills/plan-work/REFERENCE.md

@@ -30,8 +30,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/skills/plan-work/SKILL.md

@@ -51,7 +51,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:
 

package/skills/using-bigpowers/SKILL.md

@@ -78,7 +78,7 @@ UTILITY     terse-mode / craft-skill / edit-document (any phase)
 
 If you work alone and do not want PR ceremony every task:
 
-1. Read [profiles/solo-git.md](../profiles/solo-git.md).
+1. Read [profiles/solo-git.md](../../profiles/solo-git.md).
 2. Register with `compose-workflow` → `specs/WORKFLOW-solo-git.md`.
 3. Ship with `release-branch` in **solo-local** mode (`land-branch.sh`), not `gh pr create`.
 

package/skills/write-document/REFERENCE.md

@@ -141,7 +141,7 @@ Auto-fill from CLAUDE.md `Test` and `Lint` commands.
 ```markdown
 ## Changelog
 
-See [CHANGELOG.md](CHANGELOG.md) or [Releases](https://github.com/user/repo/releases).
+See [CHANGELOG.md](../../CHANGELOG.md) or [Releases](https://github.com/user/repo/releases).
 ```
 
 ### 13. Links
@@ -158,7 +158,7 @@ See [CHANGELOG.md](CHANGELOG.md) or [Releases](https://github.com/user/repo/rele
 ```markdown
 ## License
 
-MIT — see [LICENSE](LICENSE) for details.
+MIT — see [LICENSE](../../LICENSE) for details.
 ```
 
 Detect from CLAUDE.md or project LICENSE file.

package/skills-lock.json

@@ -13,7 +13,7 @@
     },
     "audit-code": {
       "description": "Self-review checklist for the coding agent to run before dispatching a reviewer. Checks CONVENTIONS.md compliance, Boy Scout Rule, test coverage, types, and SOLID. Produces a pass/fail checklist. Use before request-review, before committing, or when user asks for a code quality check.",
-      "sha256": "bbb128254464f8f4",
+      "sha256": "0636f1d9d6c591a3",
       "path": "skills/audit-codeSKILL.md"
     },
     "audit-plan": {
@@ -23,7 +23,7 @@
     },
     "build-epic": {
       "description": "Eight-step epic build cycle — reads state.yaml, execution-status.yaml, and one epic capsule; updates status via bp-yaml-set or direct edit. Resume mode runs one step per invocation. Use instead of ad-hoc execute-plan for release work.",
-      "sha256": "85275fd5f2f5664f",
+      "sha256": "11fe35d1dcdec25a",
       "path": "skills/build-epicSKILL.md"
     },
     "change-request": {
@@ -48,7 +48,7 @@
     },
     "craft-skill": {
       "description": "Create new bigpowers skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, or build a new skill for the bigpowers lifecycle.",
-      "sha256": "cbf8ab939cfbab87",
+      "sha256": "2caa9d8ae9298b4b",
       "path": "skills/craft-skillSKILL.md"
     },
     "deepen-architecture": {
@@ -108,7 +108,7 @@
     },
     "elaborate-spec": {
       "description": "Refine a rough idea into a clear, detailed specification through dialogue. Does not produce code. Use when user has a vague idea, wants to think through a feature before planning, or needs to turn \"I want X\" into a concrete spec.",
-      "sha256": "62ebfca87e6d0162",
+      "sha256": "9307ab61c789a0a0",
       "path": "skills/elaborate-specSKILL.md"
     },
     "enforce-first": {
@@ -141,6 +141,11 @@
       "sha256": "ed37c315dcef6f87",
       "path": "skills/gate-traceSKILL.md"
     },
+    "generate-allure-report": {
+      "description": "\"Generate Allure-ready reports from bigpowers YAML metadata. Reads execution-status.yaml, release-plan.yaml, epic capsules, task YAMLs, cycle-times.yaml, and bug registry to produce allure-results/junit-results.xml, categories.json, and executor.json. Use when preparing progress dashboards, integrating with Allure TestOps, or generating CI reports.\"",
+      "sha256": "acaa43602dc56291",
+      "path": "skills/generate-allure-reportSKILL.md"
+    },
     "grill-me": {
       "description": "Interactive assumption-surfacing Q&A that stress-tests a plan through relentless questioning until every decision is resolved. Use when user wants to challenge a plan, validate decisions from conversation/context, or mentions \"grill me\". For doc-grounded variant, use grill-with-docs.",
       "sha256": "8ef90da0f127f2fd",
@@ -153,9 +158,14 @@
     },
     "guard-git": {
       "description": "Block dangerous git commands (push, force push, reset --hard, clean, branch -D, checkout/restore .) and enforce Conventional Commits & Branch Protection before an AI agent runs them. Installs hook scripts for Claude Code, Cursor, Cursor CLI, and Gemini CLI; documents Google Antigravity Terminal deny lists. Use when the user wants git safety hooks, to block git push or destructive git in agents, or to mirror the same policy across AI coding tools.",
-      "sha256": "9ee881df89273b00",
+      "sha256": "e7083cba6d95a15f",
       "path": "skills/guard-gitSKILL.md"
     },
+    "harden-vps": {
+      "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.\"",
+      "sha256": "6ea255a1777523d9",
+      "path": "skills/harden-vpsSKILL.md"
+    },
     "hook-commits": {
       "description": "Set up pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.",
       "sha256": "ac5be2537ce599d7",
@@ -168,7 +178,7 @@
     },
     "investigate-bug": {
       "description": "Investigate a bug or issue by exploring the codebase to find root cause, then write a TDD-based fix plan to specs/bugs/BUG-*.md. Use when user reports a bug, wants to investigate a problem, mentions \"triage\", or wants to plan a fix.",
-      "sha256": "b842fd329d1f7741",
+      "sha256": "54f8c5417be34ef0",
       "path": "skills/investigate-bugSKILL.md"
     },
     "kickoff-branch": {
@@ -208,12 +218,12 @@
     },
     "plan-refactor": {
       "description": "Create a detailed refactor plan with tiny commits via user interview, then save it as specs/REFACTOR_LATEST.md. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.",
-      "sha256": "c418c850806e2f16",
+      "sha256": "2d18809da7cc9de8",
       "path": "skills/plan-refactorSKILL.md"
     },
     "plan-release": {
       "description": "\"RELEASE-INDEX BUILDER — Sequence elaborated epics into specs/release-plan.yaml with WSJF ordering and BCP baselines. NOT a planning-spine substitute: it does not scope work (scope-work) or write story tasks (plan-work). Use after elaborate-spec when the user wants a versioned release index of epics.\"",
-      "sha256": "62dc272a091c8d7f",
+      "sha256": "9334ff48e5b1fab3",
       "path": "skills/plan-releaseSKILL.md"
     },
     "plan-tests": {
@@ -223,7 +233,7 @@
     },
     "plan-work": {
       "description": "\"PLANNING SPINE STEP 3 of 3 — Plan the work: write detailed implementation tasks into the active epic capsule (specs/epics/eNN-slug/). Produces countable-story-format .md specs and runnable -tasks.yaml files. Use after slice-tasks (step 2). Not a substitute for scope-work (step 1) or slice-tasks (step 2).\"",
-      "sha256": "aabc7f15b46525c2",
+      "sha256": "2cccc734ae9781ab",
       "path": "skills/plan-workSKILL.md"
     },
     "publish-package": {
@@ -348,7 +358,7 @@
     },
     "using-bigpowers": {
       "description": "One-time bootstrap that introduces the bigpowers skills system, the PMBOK lifecycle arc, and tells you which skill to call first for your situation. Use when starting with bigpowers for the first time, when user asks \"where do I start?\", or when the skills system needs to be explained.",
-      "sha256": "332d6468868b759b",
+      "sha256": "bad9ebe9bf303b36",
       "path": "skills/using-bigpowersSKILL.md"
     },
     "validate-contracts": {