bigpowers 2.86.4 → 2.86.5

package/scripts/test-target-contracts.sh

@@ -0,0 +1,73 @@
+#!/usr/bin/env bash
+# story: e37s08
+# test-target-contracts.sh — anti-vacuity guard for run_contract.
+#
+# Every contract named in scripts/targets.yaml must have a real assertion behind
+# it. run_contract used to end in `*) echo "SKIP ..."; return 0`, so seven
+# declared contracts (cline/codebuddy/codex/kilocode/qwen/trae/windsurf
+# _hooks_manifest) silently passed forever. This test fails if that default ever
+# returns to being permissive, or if targets.yaml declares a contract nothing
+# implements.
+#
+# Usage: bash scripts/test-target-contracts.sh
+set -euo pipefail
+source "$(dirname "${BASH_SOURCE[0]}")/lib/skill-common.sh"
+resolve_repo_root
+cd "$REPO_ROOT"
+
+PASS=0
+FAIL=0
+pass() { echo "PASS: $1"; PASS=$((PASS + 1)); }
+fail() { echo "FAIL: $1" >&2; FAIL=$((FAIL + 1)); }
+
+echo "=== test-target-contracts.sh ==="
+
+# shellcheck source=lib/target-contracts.sh
+source "$REPO_ROOT/scripts/lib/target-contracts.sh"
+
+# 1. An unknown contract MUST fail. This is the anti-vacuity assertion.
+set +e
+out=$(run_contract "faketarget" "definitely_not_a_real_contract" 2>&1)
+rc=$?
+set -e
+if [[ $rc -ne 0 ]]; then
+  pass "unknown contract fails (exit $rc)"
+else
+  fail "unknown contract returned 0 — run_contract is fail-open again: $out"
+fi
+
+# 2. Every contract declared in targets.yaml must resolve to an assertion.
+#    Probing with a nonexistent target id means a real assertion returns 1 with
+#    a FAIL line, while a missing implementation hits the default branch and
+#    reports "unknown contract".
+declared=$(grep -E "^      - [a-z0-9_]+$" scripts/targets.yaml | sed 's/^      - //' | sort -u)
+[[ -n "$declared" ]] || fail "no contracts parsed from targets.yaml"
+
+for c in $declared; do
+  set +e
+  out=$(run_contract "__probe__" "$c" 2>&1)
+  set -e
+  if grep -q "unknown contract" <<<"$out"; then
+    fail "$c declared in targets.yaml but no assertion implements it"
+  else
+    pass "$c has an implementation"
+  fi
+done
+
+# 3. Every *_hooks_manifest target must actually ship a parseable manifest.
+for c in $declared; do
+  case "$c" in
+    gemini_hooks_manifest) continue ;;  # adapter-level validator, not a file check
+    *_hooks_manifest)
+      t="${c%_hooks_manifest}"
+      if [[ -f "scripts/hooks/${t}/hooks-manifest.json" ]]; then
+        pass "$t ships hooks-manifest.json"
+      else
+        fail "$t declares $c but scripts/hooks/${t}/hooks-manifest.json is missing"
+      fi
+      ;;
+  esac
+done
+
+echo "test-target-contracts: $PASS passed, $FAIL failed"
+[[ "$FAIL" -eq 0 ]] || exit 1

package/scripts/tombstone-skill.sh

@@ -54,9 +54,15 @@ STORY_TAGS=$(grep -E '^#\s*story:' "$OLD_SKILL_MD" || true)
 CURRENT_VERSION=$(jq -r '.version' package.json 2>/dev/null)
 CREATED_AT=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
 
+# A tombstone is still a live SKILL.md for its transition window, so it must
+# carry the same required frontmatter as any other skill. Omitting `model:`
+# made docs/references/model-profiles.md count one fewer skill than there are
+# skill directories, which fails validate-doctrine's skill-count check.
 cat > "$OLD_SKILL_MD" <<STUBEOF
 ---
 name: ${OLD_NAME}
+model: haiku
+effort: light
 description: "TOMBSTONE — renamed/merged to ${NEW_NAME}. This stub resolves for one release then is removed."
 ---
 

package/skills/craft-skill/SKILL.md

@@ -48,7 +48,7 @@ Skill-body instructional prose MUST follow [AGENTIC-STE.md](../../docs/AGENTIC-S
    - Any reference materials to include?
    - What specs/ output does it produce (if any)?
 
-2. **Verify Principles** — Ensure the skill aligns with [PRINCIPLES.md](https://github.com/danielvm-git/bigpowers/blob/main/docs/PRINCIPLES.md):
+2. **Verify Principles** — Ensure the skill aligns with [PRINCIPLES.md](../../docs/PRINCIPLES.md):
    - Is it atomic (verb-noun)?
    - Is it "deep" (simple interface, complex internal logic)?
    - Does it include Hard Gates?
@@ -62,7 +62,7 @@ Skill-body instructional prose MUST follow [AGENTIC-STE.md](../../docs/AGENTIC-S
    **Auto-skill from library README:** When user provides a library README or API docs URL, extract triggers and HARD GATEs.
    Draft verify commands and specs/ output into SKILL.md. Do NOT invent APIs not in the source.
 
-4. Add `model:` frontmatter (`haiku` | `sonnet` | `opus`) per [model-profiles.md](https://github.com/danielvm-git/bigpowers/blob/main/docs/references/model-profiles.md).
+4. Add `model:` frontmatter (`haiku` | `sonnet` | `opus`) per [model-profiles.md](../../docs/references/model-profiles.md).
 
 > **STREAM CONTINUITY** — When writing file content, output in continuous chunks of ~200 lines. Do not pause. Continue immediately until complete. If you need time, emit a placeholder comment rather than going silent.
 

package/skills/define-success/SKILL.md

@@ -1,69 +1,15 @@
-ARCHIVED: content absorbed into plan-work
-
 ---
 name: define-success
-model: sonnet
-effort: standard
-description: 'Convert an imperative task statement into explicit "step → verify: <cmd>" pairs before implementation begins. Use before plan-work when success criteria are unclear, when a task lacks verifiable checkpoints, or when user says "how will we know this is done?".'
+model: haiku
+effort: light
+description: "TOMBSTONE — renamed/merged to plan-work. This stub resolves for one release then is removed."
 ---
 
-# Define Success
-
-Transform "do X" into "step → verify: <cmd>" pairs. This is the pre-flight check before `plan-work` or `develop-tdd` — it makes success observable and removes ambiguity about when you're done.
-
-> **HARD GATE** — Success criteria must be testable and user-observable. "Code should be fast" is not testable. "Pageload latency < 2s" is testable.
-
-## Why this matters
-
-"Implement user authentication" is not a plan. It has no checkpoints, no evidence requirement, and no way to know if you're done. The Karpathy principle: every step must be independently verifiable with a runnable command. If you can't verify it, you can't prove it works.
-
-## Process
-
-### 1. Read the task statement
-
-Take the task as stated (from conversation, or from `specs/epics/ (see slice-tasks)`, or from `specs/product/SCOPE_LATEST.yaml`).
-
-### 2. Break into observable outcomes
-
-For each thing the task requires, identify:
-- The smallest unit of observable behavior that proves something works
-- The command that proves it
-
-Work at the level of behaviors (what the system does) not implementation steps (how you'll write the code).
-
-### 3. Write the pairs
-
-Format each pair as:
-```
-N. [What must be true] → verify: <runnable command>
-```
-
-Examples:
-
-```
-Task: "Add user registration to the API"
-
-1. POST /users accepts {email, name} and returns {id, email, name} → verify: curl -s -X POST http://localhost:3000/users -H 'Content-Type: application/json' -d '{"email":"test@test.com","name":"Test"}' | jq .id
-2. Duplicate email is rejected with 409 → verify: npm test -- user-registration.test.ts
-3. Missing email is rejected with 400 and descriptive error → verify: npm test -- user-validation.test.ts
-4. Password is hashed (never stored in plaintext) → verify: npm test -- user-security.test.ts
-5. All existing tests still pass → verify: npm test
-```
-
-### 4. Challenge completeness
-
-Ask yourself:
-- Is there any behavior the task requires that isn't covered by a verify step?
-- Is every verify step runnable right now without additional setup?
-- Does the final step verify the whole thing end-to-end?
-
-Add any missing pairs.
-
-### 5. Output
+# define-success (tombstoned)
 
-Present the pairs to the user and ask: "Does this capture everything the task requires? Anything missing?"
+This skill has been renamed or merged into `plan-work`. Use `plan-work` instead.
 
-Once confirmed, these pairs become the skeleton for `plan-work`'s steps. Pass them along when calling `plan-work`.
+This stub exists for one release as a transition aid, then is removed once
+`scripts/validate-tombstones.sh` flags it as expired.
 
-## Verify
 

package/skills/deploy/SKILL.md

@@ -74,7 +74,7 @@ Platform-agnostic — supports multiple deployment targets via environment varia
 |----------|---------|---------|
 | Vercel | `VERCEL_TOKEN`, `VERCEL_PROJECT_ID` | `vercel deploy --prod --token $VERCEL_TOKEN` |
 | Netlify | `NETLIFY_AUTH_TOKEN`, `NETLIFY_SITE_ID` | `netlify deploy --prod --auth $NETLIFY_AUTH_TOKEN --dir $ARTIFACT_DIR` |
-| BigBase MCP | MCP tool call | `mcp deploy` via BigBase server |
+| Platform MCP | MCP tool call | `mcp deploy` via your platform MCP server |
 | rsync/SSH | `DEPLOY_SSH_USER`, `DEPLOY_SSH_HOST`, `DEPLOY_SSH_PATH` | `rsync -avz $ARTIFACT_DIR/ $DEPLOY_SSH_USER@$DEPLOY_SSH_HOST:$DEPLOY_SSH_PATH` |
 | Custom | `DEPLOY_COMMAND` | Run any deploy command string |
 

package/skills/elaborate-spec/SKILL.md

@@ -65,7 +65,7 @@ Once the user has answered the main questions, probe for assumptions:
 
 ### 4. Synthesize and confirm
 
-Summarize your understanding in 3–5 bullet points aligned with [countable-story-format.md](https://github.com/danielvm-git/bigpowers/blob/main/docs/countable-story-format.md):
+Summarize your understanding in 3–5 bullet points aligned with [countable-story-format.md](../../docs/countable-story-format.md):
 - The problem (feeds into §1 Business narrative)
 - The solution and main flow (feeds into §5)
 - The key constraints and alternative flows (feeds into §6)

package/skills/harden-vps/REFERENCE.md

@@ -2,47 +2,47 @@
 
 ## 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
@@ -59,11 +59,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]
@@ -83,17 +83,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; }
@@ -122,9 +125,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=
@@ -133,13 +136,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>
@@ -151,7 +154,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)
@@ -164,7 +167,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/skills/harden-vps/SKILL.md

@@ -1,17 +1,17 @@
 ---
 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."
+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."
 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.
+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](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.
 
@@ -36,21 +36,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)
@@ -58,14 +58,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
@@ -73,14 +73,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
@@ -88,7 +88,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
 
@@ -97,10 +97,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
 ```
 

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](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/skills/orchestrate-project/REFERENCE.md

@@ -19,7 +19,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/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](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/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/skills/plan-work/SKILL.md

@@ -18,7 +18,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/skills/security-review/fixtures/CWE-639-idor-negative.go

@@ -5,7 +5,7 @@
 // is part of the WHERE clause. A caller from another organization gets zero
 // rows rather than someone else's site.
 //
-// Note the retrofit trap this deliberately avoids: bigbase's BUG-2026-07-24T184443
+// Note the retrofit trap this deliberately avoids: a real-world IDOR retrofit (BUG-2026-07-24T184443)
 // added `org_id INTEGER NOT NULL DEFAULT 0`, which passed tests on new rows and
 // hid 8 of 9 production sites whose legacy rows defaulted to org 0. Scope on a
 // real, backfilled org_id — never a placeholder default.

package/skills/security-review/fixtures/CWE-639-idor-positive.go

@@ -1,7 +1,7 @@
 // story: e80s05
 // Positive fixture: IDOR / missing tenant scoping (must be flagged).
 //
-// Modelled on the bigbase family (BUG-129/130/133/135/136/140/143): the
+// Modelled on a real-world bug family (BUG-129/130/133/135/136/140/143): the
 // handler authenticates the caller, then trusts an ID from the request and
 // queries by that ID alone. Authentication is proven; authorization is not.
 // Nothing in the type system or a diff-scoped review makes this look wrong —

package/skills/using-bigpowers/SKILL.md

@@ -9,7 +9,7 @@ description: One-time bootstrap that introduces the bigpowers skills system, the
 > **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`](../../SKILL-INDEX.md); never hardcode the number here.
 
 ## Install
 
@@ -38,7 +38,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/skills/wire-ci/REFERENCE.md

@@ -145,7 +145,7 @@ jobs:
 
 ---
 
-## Reference block 2 — deploy.yml (BigBase, excerpt)
+## Reference block 2 — deploy.yml (generic web app, excerpt)
 
 ```yaml
 name: Deploy
@@ -163,7 +163,7 @@ concurrency:
   cancel-in-progress: false
 
 env:
-  SITE_URL: "https://CHANGE-ME.bigbase.click"
+  SITE_URL: "https://CHANGE-ME.example.com"
 
 jobs:
   deploy:
@@ -179,18 +179,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