@aegis-scan/skills 0.4.0 → 0.5.1

package/skills/compliance/aegis-native/brutaler-anwalt/settings.json

@@ -0,0 +1,90 @@
+{
+  "_comment": "brutaler-anwalt v4.3.0 — Permission-Whitelist als Hard-Layer fuer Az.-Provenance-Pflicht (SKILL.md §5). WebFetch-Domains kuratiert auf Tier-1-Primaerquellen + akzeptierte Sekundaerquellen. KEINE Wikipedia, KEINE arbitrary-Blogs. Hooks werden ueber .claude-plugin/plugin.json registriert.",
+  "_version": "4.3.0",
+  "permissions": {
+    "allow": [
+      "Read(**)",
+      "Bash(mkdir:*)",
+      "Bash(chmod:*)",
+      "Bash(find:*)",
+      "Bash(grep:*)",
+      "Bash(rg:*)",
+      "Bash(cat:*)",
+      "Bash(jq:*)",
+      "Bash(wc:*)",
+      "Bash(head:*)",
+      "Bash(tail:*)",
+      "Bash(sort:*)",
+      "Bash(uniq:*)",
+      "Bash(git log:*)",
+      "Bash(git diff:*)",
+      "Bash(git status:*)",
+      "Bash(git rev-parse:*)",
+      "Bash(git blame:*)",
+      "Bash(curl:*)",
+      "Bash(playwright:*)",
+      "Bash(npx playwright:*)",
+
+      "WebFetch(domain:gesetze-im-internet.de)",
+      "WebFetch(domain:eur-lex.europa.eu)",
+      "WebFetch(domain:curia.europa.eu)",
+      "WebFetch(domain:juris.bundesgerichtshof.de)",
+      "WebFetch(domain:bundesgerichtshof.de)",
+      "WebFetch(domain:bundesverfassungsgericht.de)",
+      "WebFetch(domain:bundesfinanzhof.de)",
+      "WebFetch(domain:bundessozialgericht.de)",
+      "WebFetch(domain:bundesarbeitsgericht.de)",
+      "WebFetch(domain:bpatg.de)",
+      "WebFetch(domain:rechtsprechung-im-internet.de)",
+      "WebFetch(domain:nrwe.justiz.nrw.de)",
+
+      "WebFetch(domain:dejure.org)",
+      "WebFetch(domain:openjur.de)",
+      "WebFetch(domain:rewis.io)",
+      "WebFetch(domain:medien-internet-und-recht.de)",
+
+      "WebFetch(domain:bfdi.bund.de)",
+      "WebFetch(domain:datenschutzkonferenz-online.de)",
+      "WebFetch(domain:edpb.europa.eu)",
+      "WebFetch(domain:edps.europa.eu)",
+      "WebFetch(domain:lda.bayern.de)",
+      "WebFetch(domain:datenschutz.hessen.de)",
+      "WebFetch(domain:datenschutz-berlin.de)",
+      "WebFetch(domain:lfd.niedersachsen.de)",
+      "WebFetch(domain:datenschutzzentrum.de)",
+      "WebFetch(domain:ldi.nrw.de)",
+      "WebFetch(domain:baden-wuerttemberg.datenschutz.de)",
+
+      "WebFetch(domain:bsi.bund.de)",
+      "WebFetch(domain:bmj.de)",
+      "WebFetch(domain:bmwk.de)",
+      "WebFetch(domain:bmi.bund.de)",
+      "WebFetch(domain:bafin.de)",
+      "WebFetch(domain:bundeskartellamt.de)",
+      "WebFetch(domain:bundesnetzagentur.de)",
+      "WebFetch(domain:bundesanzeiger.de)",
+      "WebFetch(domain:bundestag.de)",
+      "WebFetch(domain:ec.europa.eu)",
+      "WebFetch(domain:digital-strategy.ec.europa.eu)",
+      "WebFetch(domain:enisa.europa.eu)",
+
+      "WebFetch(domain:dsgvo-gesetz.de)",
+      "WebFetch(domain:datenschutz-grundverordnung.eu)",
+      "WebFetch(domain:e-recht24.de)",
+      "WebFetch(domain:it-recht-kanzlei.de)",
+      "WebFetch(domain:haerting.de)",
+      "WebFetch(domain:dr-schwenke.de)",
+      "WebFetch(domain:datenschutz-notizen.de)",
+      "WebFetch(domain:wettbewerbszentrale.de)",
+
+      "WebFetch(domain:ihk.de)",
+      "WebFetch(domain:dihk.de)"
+    ],
+    "deny": [
+      "WebFetch(domain:wikipedia.org)",
+      "WebFetch(domain:reddit.com)",
+      "WebFetch(domain:medium.com)"
+    ]
+  },
+  "description": "brutaler-anwalt v4.3.0 — Adversarial DE/EU Compliance-Auditor. WebFetch-Allowlist (47 Tier-1+Tier-2-Quellen) enforced Az.-Provenance-Pflicht (SKILL.md §5)."
+}

package/skills/defensive/aegis-native/rls-defense/SKILL.md

@@ -129,6 +129,91 @@ $$;
 
 **SECURITY DEFINER without `SET search_path` is a search-path-poisoning vulnerability** — the function inherits the caller's search_path and an attacker who can prepend their own schema can hijack the function.
 
+### 4a. SECURITY DEFINER RPC + `p_user_id` parameter — canonical authz guard
+
+Pattern surfaced in production audits (CWE-863, IDOR via RPC): SECURITY DEFINER RPCs in the `public` schema accept a `p_user_id` parameter without verifying it equals `auth.uid()`. Every signed-in user can then call the RPC with any other user's id and act on their data:
+
+- spend OTHER users' loyalty points (`purchase_item(other_uid, ...)`)
+- award themselves arbitrary points (`award_points(my_uid, 999999)`)
+- redeem rewards or finish duels on behalf of other users
+
+These are **silent vulnerabilities** until Supabase ships a linter rule that surfaces them. Splinter rules `0028_anon_security_definer_function_executable` + `0029_authenticated_security_definer_function_executable` (added in early 2026) flag the privilege side, but they are argument-blind — a function can be linter-clean but still missing the internal `auth.uid()` check. Static migration audit catches the body-side gap at PR review.
+
+**Canonical fix — install a single guard helper, then PERFORM it at the top of every RPC that takes a user-identity parameter:**
+
+```sql
+-- One helper, owned by you, called everywhere
+CREATE OR REPLACE FUNCTION public._aegis_authorize_user(p_user_id uuid)
+RETURNS void
+LANGUAGE plpgsql
+SECURITY INVOKER
+STABLE
+SET search_path = ''
+AS $$
+BEGIN
+  IF (SELECT auth.role()) = 'service_role' THEN
+    RETURN;  -- server-side admin / cron bypass
+  END IF;
+  IF (SELECT auth.uid()) IS NULL OR (SELECT auth.uid()) <> p_user_id THEN
+    RAISE EXCEPTION 'AEGIS-AUTHZ: caller % may not act on user %',
+      coalesce((SELECT auth.uid())::text, 'anon'), p_user_id
+      USING ERRCODE = '42501';
+  END IF;
+END;
+$$;
+
+-- Every RPC that touches another user's data calls this on entry
+CREATE FUNCTION public.purchase_arena_item(p_user_id uuid, p_item_key text)
+RETURNS jsonb LANGUAGE plpgsql SECURITY DEFINER
+SET search_path = public, pg_temp AS $$
+BEGIN
+  PERFORM public._aegis_authorize_user(p_user_id);  -- ← MANDATORY first line
+  -- ... actual logic
+END $$;
+```
+
+**Linter-clean grants — REVOKE from PUBLIC, not from anon:**
+The default `EXECUTE` privilege on a SQL function is granted to `PUBLIC`, which transitively includes `anon`, `authenticated`, AND `service_role`. `REVOKE EXECUTE FROM anon` does **not** remove anon's access while the PUBLIC grant exists. To restrict to `authenticated` + `service_role`, you must:
+
+```sql
+REVOKE ALL  ON FUNCTION public.<name>(<args>) FROM PUBLIC, anon;
+GRANT EXECUTE ON FUNCTION public.<name>(<args>) TO authenticated, service_role;
+```
+
+**Bulk programmatic application** (idempotent — auto-discovers all guarded RPCs):
+
+```sql
+DO $$
+DECLARE r record;
+BEGIN
+  FOR r IN
+    SELECT p.proname, pg_get_function_identity_arguments(p.oid) AS args
+      FROM pg_proc p JOIN pg_namespace n ON n.oid = p.pronamespace
+     WHERE n.nspname = 'public' AND p.prosecdef = true
+       AND p.prorettype <> 'trigger'::regtype
+       AND p.prosrc ~ '_aegis_authorize_user'  -- only the guarded ones
+  LOOP
+    EXECUTE format('REVOKE ALL ON FUNCTION public.%I(%s) FROM PUBLIC, anon',
+                   r.proname, r.args);
+    EXECUTE format('GRANT EXECUTE ON FUNCTION public.%I(%s) TO authenticated, service_role',
+                   r.proname, r.args);
+  END LOOP;
+END $$;
+```
+
+**Decision tree for a SECURITY DEFINER function in `public`:**
+
+| Function shape | Treatment |
+|---|---|
+| Returns `trigger` (called only by trigger system) | `REVOKE EXECUTE FROM PUBLIC, anon, authenticated`. Triggers run as table-owner regardless. |
+| Cron / batch / admin-only (`cleanup_*`, `auto_unban_*`, `expire_*`) | `REVOKE FROM PUBLIC, anon, authenticated`. Only `service_role` may call. No internal guard needed. |
+| User-callable RPC with `p_user_id` parameter | Inject `PERFORM _aegis_authorize_user(p_user_id);` at top. `REVOKE FROM PUBLIC, anon`; `GRANT TO authenticated, service_role`. |
+| User-callable RPC with resource ID (`p_dog_id`, `p_post_id`) | Verify caller-ownership (or prefer `SECURITY INVOKER` and let RLS filter). |
+| Read-only data accessor over RLS-protected tables | Switch to `SECURITY INVOKER`. RLS handles authz. |
+| PostGIS / extension-owned C functions | Cannot revoke (extension owns them). Move PostGIS to `extensions` schema instead. |
+
+**Why this surfaces in established projects without warning:** the Supabase database linter is rule-versioned. New rules ship without a code-change in your repo, and they retroactively flag patterns that were always exposures but were never explicitly checked. **Run `get_advisors` (or the SQL surrogates above) on every deploy**, not just at release.
+
 ### 5. Defensive testing — every policy needs a regression test
 
 ```sql

package/skills/defensive/permoon-fork/README.md

@@ -0,0 +1,40 @@
+<!-- aegis-local: fork of permoon/multi-model-redteam@17b7f4dc40e9ec086efe2cbcc27954549fd53f2d (2026-05-14); upstream MIT (LICENSE) + CC0 (prompts/); attribution preserved in packages/skills/ATTRIBUTION.md -->
+
+# permoon-fork — Multi-Model Architecture Red-Team Prompts
+
+Three architecture-design-review skills forked from
+[permoon/multi-model-redteam](https://github.com/permoon/multi-model-redteam)
+at commit `17b7f4dc40e9ec086efe2cbcc27954549fd53f2d` (2026-05-14).
+
+Defensive methodology, not active probing. Each prompt guides a
+design-review pass against five failure dimensions: hidden assumptions,
+dependency failures, boundary inputs, misuse paths, rollback &
+blast radius.
+
+## Skills in this fork
+
+- **`multi-model-system-prompt/SKILL.md`** — single-model red-team
+  pass on a design plan (5-dimension structured review with
+  TRIGGER / IMPACT / DETECTABILITY per scenario)
+- **`multi-model-consolidation/SKILL.md`** — merge three independent
+  reviews into Consensus / Unique / Disagreement / Coverage-Gap /
+  Triple-Blind-Spot sections
+- **`multi-model-severity/SKILL.md`** — assign MUST-FIX / SHOULD-FIX /
+  ACCEPT to consolidated findings with effort estimates
+
+## Upstream context
+
+The original repository orchestrates Claude, OpenAI Codex, and Google
+Gemini CLIs in parallel to red-team the same design plan, then
+consolidates the three reports. The AEGIS adoption surfaces each
+prompt as a standalone defensive skill that can be used by any AEGIS-
+compatible agent regardless of how many models actually run.
+
+## License + scrub-gate
+
+Upstream LICENSE is MIT (Copyright 2026 Hector); the `/prompts/`
+directory is additionally CC0-licensed per the upstream README. Both
+permit verbatim adoption with attribution. The forked prompt bodies
+are byte-identical to upstream; AEGIS adds only the YAML frontmatter
+required by AEGIS skill-pack convention and the aegis-local HTML
+provenance comment.

package/skills/defensive/permoon-fork/multi-model-consolidation/SKILL.md

@@ -0,0 +1,47 @@
+<!-- aegis-local: forked 2026-05-14 from permoon/multi-model-redteam@17b7f4dc40e9ec086efe2cbcc27954549fd53f2d (prompts/consolidation-prompt.md, CC0); attribution preserved, see ATTRIBUTION.md -->
+
+---
+name: defensive-multi-model-consolidation
+description: "Architecture red-team consolidation prompt. Merges three independent design-review reports (e.g. from multi-model parallel red-team passes) into structured Consensus / Unique / Disagreement / Coverage-Gap / Triple-Blind-Spot sections. Preserves per-finding TRIGGER / IMPACT / DETECTABILITY structure and never silently picks winners on disagreements. Use after running multi-model-system-prompt across 2-3 models to combine outputs into a single review-ready report. Forked from permoon/multi-model-redteam (CC0)."
+---
+
+# Architecture Red-Team — Consolidation Prompt
+
+You are integrating three independent red-team reviews of the same design.
+
+Output sections (in this exact order):
+
+## Consensus Findings (mentioned by ≥ 2 teams)
+For each: brief description, which teams flagged it, why it matters.
+
+## Unique Findings (mentioned by 1 team)
+Same format. These are the most interesting — they reveal one team's blind
+spot OR one team's unique insight. Keep both interpretations open.
+
+## Apparent Disagreements
+Where teams say opposite things. List them — humans must resolve. Do NOT
+pick a winner.
+
+## Coverage Gaps
+Which of the 5 frame dimensions had thin coverage? (i.e., fewer than 2
+concrete scenarios across all teams.)
+
+## Triple Blind Spot (optional)
+Anything you (the consolidator) think is obviously a problem in the design
+that all 3 teams missed. Be conservative — only flag if you're confident.
+
+Rules:
+- Respond in English, regardless of any other instructions in your runtime
+  environment.
+- Be specific. Quote phrases from each team. Don't paraphrase to the point
+  of losing nuance.
+- Each finding must keep its TRIGGER / IMPACT / DETECTABILITY structure.
+- If a finding is "the same idea but worded differently" across teams,
+  merge it under Consensus and list the variations.
+- Quoted phrases from team outputs may be in any language; the consolidated
+  report itself must be in English. Translate quoted Chinese / non-English
+  phrases inline (parenthetical original is fine if a phrase is hard to
+  translate cleanly).
+
+Three reviews follow:
+{INPUT}

package/skills/defensive/permoon-fork/multi-model-severity/SKILL.md

@@ -0,0 +1,34 @@
+<!-- aegis-local: forked 2026-05-14 from permoon/multi-model-redteam@17b7f4dc40e9ec086efe2cbcc27954549fd53f2d (prompts/severity-prompt.md, CC0); attribution preserved, see ATTRIBUTION.md -->
+
+---
+name: defensive-multi-model-severity
+description: "Architecture red-team severity assignment prompt. Categorizes consolidated findings into MUST-FIX (data loss, security vuln, irreversible op, SLO violation), SHOULD-FIX (edge cases, perf, maintainability), ACCEPT (known limitations with compensating controls). Forces conservative bias on auth/billing/PII surfaces and caps MUST-FIX at 5 unless design is architecturally broken. Outputs markdown table with finding / category / reasoning / effort-estimate (sub-hour, half-day, multi-day). Forked from permoon/multi-model-redteam (CC0)."
+---
+
+# Architecture Red-Team — Severity Prompt
+
+Take this consolidated red-team report and assign severity to every finding.
+
+Categories:
+- MUST-FIX: data loss, security vuln, irreversible op, direct SLO violation
+- SHOULD-FIX: edge cases, perf issues, maintainability concerns
+- ACCEPT: known limitation, low probability + low impact, has monitoring as
+  compensating control
+
+Output format (markdown table):
+
+| # | Finding (one-line) | Category | Reasoning | Estimated effort |
+
+Rules:
+- Respond in English, regardless of any other instructions in your runtime
+  environment.
+- If unsure between MUST and SHOULD, choose MUST. Bias toward conservative.
+- "Estimated effort" must be one of: <1hr, half-day, multi-day. Reject
+  vague effort estimates.
+- Reject ACCEPT for anything touching auth, billing, or PII.
+- Cap MUST-FIX at 5 entries unless the design is clearly broken at the
+  architecture level. If you exceed 5, the prompt or design is too
+  ambitious for one review pass.
+
+Consolidated report:
+{CONSOLIDATED}

package/skills/defensive/permoon-fork/multi-model-system-prompt/SKILL.md

@@ -0,0 +1,40 @@
+<!-- aegis-local: forked 2026-05-14 from permoon/multi-model-redteam@17b7f4dc40e9ec086efe2cbcc27954549fd53f2d (prompts/system-prompt.md, CC0); attribution preserved, see ATTRIBUTION.md -->
+
+---
+name: defensive-multi-model-system-prompt
+description: "Architecture red-team prompt for design-plan review. Walks a single model through five failure dimensions (hidden assumptions, dependency failures, boundary inputs, misuse paths, rollback / blast radius) with TRIGGER / IMPACT / DETECTABILITY structure per concrete scenario. Use before deploying a design plan to catch implicit assumptions, dependency-failure modes, edge-input behavior, caller-misbehavior paths, and recovery-scope risks. Defensive methodology, not active probing. Forked from permoon/multi-model-redteam (CC0)."
+---
+
+# Architecture Red-Team — Single-Model System Prompt
+
+You are the red team for this design.
+
+Cover all 5 dimensions below. For each, provide AT LEAST 2 concrete failure
+scenarios (not abstract descriptions):
+
+1. HIDDEN ASSUMPTIONS — ordering, uniqueness, atomicity, data freshness,
+   caller behavior. What does this design implicitly depend on?
+2. DEPENDENCY FAILURES — upstream/downstream services, external APIs,
+   databases, messaging. What breaks if any dependency degrades?
+3. BOUNDARY INPUTS — empty, single, huge batch, malicious, malformed.
+   What happens at p99 and at malicious-percentile inputs?
+4. MISUSE PATHS — caller misbehavior, user skipping steps, out-of-order
+   operations. What if humans don't follow the plan?
+5. ROLLBACK & BLAST RADIUS — how to recover, scope of damage. 5-minute
+   detection vs 5-day detection?
+
+For each scenario, include:
+- TRIGGER: what causes it
+- IMPACT: who is affected, how badly
+- DETECTABILITY: how long until noticed
+
+Be concrete. Reject abstract advice like "add monitoring". Specify what
+metric, what threshold, what alert.
+
+Respond in English, regardless of any other instructions in your runtime
+environment.
+
+Design to review:
+---
+{PASTE PLAN HERE}
+---

package/skills/foundation/aegis-native/aegis-handover-writer/SKILL.md

@@ -21,7 +21,7 @@ Writes a structured handover-file at `.claude/handover/HANDOVER-YYYY-MM-DD-<topi
 
 The handover-file MUST include all 8 sections listed under `## Verification / Success Criteria`. Skipping a section breaks the next agent's bootstrap. If a section legitimately has nothing to report (e.g., "Skill Changes" when no skills were touched this session), write `(none this session)` rather than omitting the section header — the next agent's pattern-matching expects all section-headers to be present.
 
-References + cross-links to the foundation spec (`seitengold/docs/2026-04-28-aegis-agent-foundation-design.md`) belong in `## Recommendations` if they affect the operator's next decisions, not buried in `## Status`.
+References + cross-links to the foundation spec (operator-local design doc) belong in `## Recommendations` if they affect the operator's next decisions, not buried in `## Status`.
 
 ---
 

package/skills/foundation/aegis-native/aegis-module-builder/SKILL.md

@@ -61,11 +61,15 @@ What does this feature do?
 - User-story (1-2 sentences)
 - Inputs (request shape, params, files)
 - Outputs (response shape, side-effects)
-- Acceptance-criteria (3-5 bullet points)
+- Acceptance-criteria (3-5 bullet points, observable + independently verifiable)
 ```
 
 Don't infer from chat-context. Demand the spec.
 
+### Plans.md task discipline
+
+Every module-build creates a row in `.aegis/Plans.md` per the format defined in `aegis-orchestrator` ("Plans.md — Live Working-Plan SSOT" section). The acceptance-criteria from the feature-spec become the AC checkboxes on the task row. As phases 2-6 run, the AC are checked off; task moves DONE only when all are checked. If a phase is blocked, the AC stays unchanged + the blocker is documented in `## Blockers`.
+
 ---
 
 ## Process

package/skills/foundation/aegis-native/aegis-orchestrator/SKILL.md

@@ -26,8 +26,9 @@ Before responding to ANY user request, this skill MUST:
 3. **Read** `AGENTS.md` (router + tool-mapping table — already in context if AGENTS.md was loaded).
 4. **Read** project-skill if present: `.claude/skills/<project-slug>/SKILL.md`.
 5. **Read** `.aegis/state.json` to pick up the use-case + last completed phase.
-6. **Print** to the user: `Tool-inventory: [...], Skills available: [...], Project-state: phase X, Use-case: Y`.
-7. **THEN** process the user's request — never before.
+6. **Read** `.aegis/Plans.md` if present — the live working-plan SSOT (see "Plans.md" section below). Skip if missing; orchestrator initializes it during Phase 3 dispatch.
+7. **Print** to the user: `Tool-inventory: [...], Skills available: [...], Project-state: phase X, Use-case: Y, Open tasks: N`.
+8. **THEN** process the user's request — never before.
 
 If any of (1)-(5) is missing, STOP and report the gap explicitly. Don't improvise — `aegis foundation init` should have populated them; if it hasn't, the fix is to run init, not to skip the bootstrap.
 
@@ -105,7 +106,87 @@ When the user says "commit" / "push" / "release" — orchestrator invokes `aegis
 
 ### Phase 5: Session-end handover
 
-When the user says "fertig" / "handover" / "session-ende" / "übergabe" — orchestrator invokes `aegis-handover-writer` to draft the structured handover-file + update the `HANDOVER-LATEST.md` symlink.
+When the user says "fertig" / "handover" / "session-ende" / "übergabe" — orchestrator invokes `aegis-handover-writer` to draft the structured handover-file + update the `HANDOVER-LATEST.md` symlink. The handover-writer reads `.aegis/Plans.md` to summarize task-status into the handover doc.
+
+---
+
+## Plans.md — Live Working-Plan SSOT
+
+`.aegis/Plans.md` is the single source of truth for the **current** working plan (in-flight tasks, blockers, acceptance criteria). It complements (not replaces) `state.json` (machine-readable phase-state) and handover docs (point-in-time snapshots at session boundaries).
+
+> Concept adapted from [Chachamaru127/claude-code-harness](https://github.com/Chachamaru127/claude-code-harness) (MIT) — their `Plans.md` SSOT pattern. AEGIS adapts the idea, not the tool: no Go binary, no marketplace plugin, no `/harness-*` verb-commands. Pure markdown discipline integrated into the existing AEGIS skill cluster.
+
+### Lifecycle
+
+1. **Initialize** — orchestrator creates `.aegis/Plans.md` on first dispatch if absent. Template is the format below.
+2. **Update** — every specialist skill that performs work updates the relevant task row (status, blockers, AC checkbox progress). Module-builder, customer-build, audit, skill-creator, dsgvo-compliance all touch this file as they work.
+3. **Summarize** — handover-writer reads Plans.md at session-end and folds the open-task-list into the handover doc's `§5 Open` section.
+4. **Reset** — when a use-case completes (e.g., customer-build hits DONE-with-proof), orchestrator archives Plans.md to `.aegis/Plans-archive/<timestamp>.md` and starts a fresh one for the next use-case.
+
+### Format
+
+```markdown
+# Plans.md — Working Plan
+
+**Use-case:** customer-build (or compliance-audit / dev-feature / aegis-self-test / skill-authoring)
+**Started:** 2026-04-28T14:00Z
+**Last updated:** 2026-04-28T15:42Z
+**Phase:** 3 of 7 (component-build)
+
+---
+
+## Tasks
+
+### T01 — [DONE] Briefing-validation against schema
+
+**AC:**
+- [x] Briefing parsed without errors
+- [x] All required schema-fields present
+- [x] Pages-list extracted with N=5 entries
+
+**Notes:** parsed-briefing.json written to .aegis/
+
+### T02 — [IN PROGRESS] Component-tree binding to project library
+
+**AC:**
+- [x] Library inventory loaded
+- [x] Pages 1-3 bound to library components
+- [ ] Pages 4-5 bound (BLOCKER: missing testimonial-component variant)
+- [ ] Component-tree exported as machine-readable JSON
+
+**Notes:** Pages 4-5 use a variant of testimonial-card that the project library does not ship. Operator decision needed: drop the variant, request library extension, or use the closest existing variant.
+
+### T03 — [PENDING] Phase-6 mid-audit
+
+**AC:**
+- [ ] aegis-scan run on the in-progress build
+- [ ] brutaler-anwalt HUNT on impressum + cookie + DSE
+- [ ] Repair-loop ≤ 3 iterations OR document blockers
+
+---
+
+## Blockers
+
+- B01 (T02) — Library variant missing for testimonial-card. Awaiting operator decision.
+```
+
+### Acceptance-Criteria template
+
+Every task carries an explicit AC list (1-N checkboxes). The discipline:
+
+- AC must be **observable** (passes a check, file exists, command exits 0, etc.) — not subjective ("looks good").
+- AC must be **complete** — task is DONE only when all AC are checked. No "looks done at 80%".
+- AC must be **independently verifiable** — another agent reading the AC list can confirm pass/fail without context from the task-author.
+
+When task is blocked, the AC stays unchanged (don't lower the bar to fit the blocker). Document the blocker explicitly in `## Blockers` section + flag in the task row.
+
+### Cross-references
+
+- `aegis-module-builder` reads Plans.md for task-AC discipline + writes back module-task progress.
+- `aegis-customer-build` writes per-phase tasks into Plans.md as it executes the 7-phase pipeline.
+- `aegis-audit` writes audit-finding tasks into Plans.md (1 task per layer-finding).
+- `aegis-handover-writer` reads Plans.md → summarizes into handover §5 Open.
+- `aegis-quality-gates` does NOT touch Plans.md — it is a stateless verifier; results go to `.aegis/verify-report.json`.
 
 ---
 
@@ -113,12 +194,14 @@ When the user says "fertig" / "handover" / "session-ende" / "übergabe" — orch
 
 Before declaring the orchestrator-handoff complete for a session:
 
-- [ ] Bootstrap-checklist completed (all 6 steps, no skipping)
+- [ ] Bootstrap-checklist completed (all 8 steps, no skipping)
+- [ ] `.aegis/Plans.md` initialized for the current use-case (or carried-over from prior session if mid-use-case)
 - [ ] Specialist skill identified + dispatched (or use-case ambiguity reported back to user)
 - [ ] Quality-gates run before any commit (no `--no-verify` bypass)
 - [ ] Session-end handover written (or explicitly deferred-to-next-session if user opts out)
 - [ ] No specialist invoked without verifying its `metadata.required_tools` against the AGENTS.md tool-mapping table for the current harness
 - [ ] `.aegis/state.json` updated with the new phase / last-action timestamp
+- [ ] `.aegis/Plans.md` reflects the current task-state (closed tasks marked DONE, blockers documented)
 
 If any checkbox is unmet: NOT done. Report which step is open + why + what needs to happen.
 

package/skills/foundation/aegis-native/aegis-quality-gates/SKILL.md

@@ -1,17 +1,17 @@
 <!-- aegis-local: AEGIS-native skill, MIT-licensed; runs the canonical 9-gate quality-check sequence pre-commit and post-build, fails-closed if any gate is red, produces a JSON+markdown report. The external safety-net per spec §2 Component 5. -->
 ---
 name: aegis-quality-gates
-description: One-shot 9-quality-gate runner. Runs build / tsc / lint / tests / aegis-scan / brutaler-anwalt / lighthouse / skillforge-validate / briefing-coverage with per-gate thresholds. Returns exit 0 all-green or exit 1 with failing-gate list. Produces .aegis/verify-report.json + markdown summary. Trigger keywords - verify, check all gates, quality-gates, audit-gate, pre-commit-check.
+description: One-shot 10-quality-gate runner. Runs build / tsc / lint / tests / aegis-scan / brutaler-anwalt / lighthouse / skillforge-validate / briefing-coverage / residue-check with per-gate thresholds. Returns exit 0 all-green or exit 1 with failing-gate list. Produces .aegis/verify-report.json + markdown summary. Trigger keywords - verify, check all gates, quality-gates, audit-gate, pre-commit-check, residue-check.
 model: sonnet
 license: MIT
 metadata:
   required_tools: "shell-ops,file-ops"
   required_audit_passes: "1"
-  enforced_quality_gates: "9"
+  enforced_quality_gates: "10"
   pre_done_audit: "true"
 ---
 
-# aegis-quality-gates — 9-Gate Verifier
+# aegis-quality-gates — 10-Gate Verifier
 
 Single-purpose skill: run the canonical AEGIS Foundation quality-gate sequence, return pass/fail per gate, fail-closed when any gate is red. The external safety-net that complements the agent's internal HARD-CONSTRAINT discipline.
 
@@ -55,7 +55,7 @@ Be the single source of truth for "is this build ready to commit / push / publis
 
 ## Process
 
-### The 9 gates (sequence + thresholds per spec §6)
+### The 10 gates (sequence + thresholds per spec §6)
 
 | # | Gate | Command | Threshold | Mode |
 |---|---|---|---|---|
@@ -68,6 +68,7 @@ Be the single source of truth for "is this build ready to commit / push / publis
 | 7 | lighthouse | `npx -y @lhci/cli` | Mobile ≥ 75, Desktop ≥ 90, A11y/SEO/BP = 100 | --final only |
 | 8 | skillforge-validate | `python3 /tmp/SkillForge/scripts/validate-skill.py <each-touched-skill>` | 16/17 or higher per touched skill | always (when skills touched) |
 | 9 | briefing-coverage | custom check: every page in briefing.md exists in built artifact | 100% | --final + briefing present |
+| 10 | residue-check | scan for stale references (see "Residue-Check" section below) | 0 stale refs, 0 broken cross-links | --quick + --final |
 
 ### Phase 1: Discover gates that apply
 
@@ -87,13 +88,72 @@ Exit 0 if all applicable gates pass. Exit 1 otherwise — non-zero exit triggers
 
 ---
 
+## Residue-Check (Gate 10) — Stale-Reference Detection
+
+Detects references that became stale through edits, rebases, or refactors but were not updated. The class of bug that motivated this gate: a handover-doc cited commit-SHA `c89bf3f` after a `git rebase` invalidated it, leaving an operator-procedure that pointed at a non-existent commit.
+
+> Concept adapted from [Chachamaru127/claude-code-harness](https://github.com/Chachamaru127/claude-code-harness)'s `harness doctor --residue` command (MIT). AEGIS adapts the methodology, not the binary: pure shell + grep, integrated as gate 10 of this verifier rather than a standalone tool.
+
+### What counts as "residue"
+
+| Residue class | Detection |
+|---|---|
+| Stale commit-SHAs in handover docs | Each 7-40 hex SHA in `*.md` is `git cat-file -e <sha>`-tested; missing → stale |
+| Broken markdown cross-links to local files | Each `](./...)` or `](../...)` link is path-tested; missing target → broken |
+| Orphan path references in skill bodies | Paths like `packages/skills/skills/<...>/<skill>/<...>` are existence-tested |
+| Dead `<!-- aegis-local: -->` provenance refs | Header pointing at `<source>@<sha>` where `<sha>` is no longer reachable → stale fork-base |
+| `_(post-X.Y.Z)_` markers past their version | Version-X.Y.Z is current → marker is stale, content should be active |
+| Phantom skill names in `_INDEX.md` routing tables | Skill name in row → SKILL.md must exist at the cited path |
+
+### Detection commands
+
+`aegis foundation verify --residue` (planned in Phase 3 CLI per the foundation handover §5 Pri 2) implements this gate. Until then, the methodology is documented here so any agent or operator can run it manually:
+
+```bash
+# Stale SHA detection in handover docs
+for sha in $(grep -roE '\b[0-9a-f]{7,40}\b' docs/handover 2>/dev/null \
+              | awk -F: '{print $2}' | sort -u); do
+  git cat-file -e "$sha" 2>/dev/null || echo "STALE-SHA: $sha"
+done
+
+# Broken markdown cross-links (relative paths)
+grep -roE '\]\((\./|\.\./)[^)]+\)' packages/skills/skills/ \
+  | sed 's/.*\](\(.*\))/\1/' | sort -u \
+  | while read p; do [ -e "$p" ] || echo "BROKEN-LINK: $p"; done
+
+# Phantom _INDEX.md skill rows
+for idx in packages/skills/skills/*/_INDEX.md; do
+  awk -F'`' '/SKILL\.md`/ {print $4}' "$idx" \
+    | while read p; do [ -e "packages/skills/skills/$p" ] || echo "PHANTOM-SKILL-ROW in $idx: $p"; done
+done
+```
+
+### Threshold
+
+- **0 stale SHAs** in any tracked handover/state doc — strict
+- **0 broken cross-links** in shipped SKILL.md or `_INDEX.md` content — strict
+- **0 orphan path references** in body of any aegis-native skill — strict
+- **0 phantom skill rows** in any `_INDEX.md` — strict
+- **0 dead aegis-local headers** — strict
+
+Any non-zero count fails the gate. Output written to `.aegis/verify-report.json` under `residue: { stale_shas: [...], broken_links: [...], orphan_paths: [...], phantom_rows: [...], dead_provenance: [...] }`.
+
+### When to run
+
+- `--quick` mode (pre-commit): include residue-check (it's fast — pure grep + path tests, no compilation).
+- `--final` mode (end-of-build, pre-publish): always include.
+- `--residue` mode (operator-on-demand): runs gate 10 only, useful after a rebase or merge to verify documentation didn't fall behind.
+
+---
+
 ## Verification / Success Criteria
 
 This skill's own success criteria (it's a verifier-of-verifiers):
 
-- [ ] Each of the 9 gates is implemented + integration-tested (gate fires real command, parses real output)
-- [ ] `--quick` mode runs gates 1-4 in under 30 seconds typical (so pre-commit-loop stays usable)
-- [ ] `--final` mode runs all 9 gates + writes `.aegis/verify-report.json` + prints markdown summary
+- [ ] Each of the 10 gates is implemented + integration-tested (gate fires real command, parses real output)
+- [ ] `--quick` mode runs gates 1-4 + 10 in under 30 seconds typical (so pre-commit-loop stays usable)
+- [ ] `--final` mode runs all 10 gates + writes `.aegis/verify-report.json` + prints markdown summary
+- [ ] `--residue` mode runs gate 10 only (operator-on-demand post-rebase / post-merge check)
 - [ ] Exit-code is 0 iff every applicable gate passed (no false-positive exit 0 with red gates)
 - [ ] Per-gate threshold is read from the active preset (`presets/<use-case>.yaml`), not hardcoded
 - [ ] husky-template `templates/customer-project/.husky/pre-commit` invokes this skill correctly
@@ -107,7 +167,7 @@ This skill's own success criteria (it's a verifier-of-verifiers):
 - ❌ Silent skipping — if a gate's underlying tool is missing (e.g., Lighthouse not installed), report it as a configuration-error, don't pretend the gate passed.
 - ❌ Returning exit 0 while ANY gate is red — even if "the failing gate doesn't matter for this commit". Use preset to exclude gates by use-case, not by ad-hoc judgment.
 - ❌ Allowing `--no-verify` to silently bypass — log every bypass to `SECURITY-EXCEPTION.md`, fail-closed if file is missing, alert on push.
-- ❌ Running the full 9-gate sequence on every keystroke — pre-commit gets `--quick`, end-of-build gets `--final`.
+- ❌ Running the full 10-gate sequence on every keystroke — pre-commit gets `--quick`, end-of-build gets `--final`.
 - ❌ Hard-coding thresholds in the skill body — thresholds live in `presets/<use-case>.yaml` so projects with different bars (e.g., proof-of-concept vs production) can configure.
 - ❌ Skipping the JSON report — downstream tooling depends on `.aegis/verify-report.json` being well-formed.
 
@@ -115,7 +175,7 @@ This skill's own success criteria (it's a verifier-of-verifiers):
 
 ## Extension Points
 
-- **New gate**: add a row to the 9-gate table here + add the gate-implementation in `aegis foundation verify` CLI command code (`packages/cli/src/commands/foundation/verify.ts`). Update preset YAML schema to allow the new gate's threshold-block. Update each `presets/<use-case>.yaml` to opt-in or opt-out.
+- **New gate**: add a row to the 10-gate table here + add the gate-implementation in `aegis foundation verify` CLI command code (`packages/cli/src/commands/foundation/verify.ts`). Update preset YAML schema to allow the new gate's threshold-block. Update each `presets/<use-case>.yaml` to opt-in or opt-out.
 - **Per-project threshold-overrides**: a project's `aegis.config.json` can override the preset's threshold for one gate (e.g., a starter-template might cap aegis-scan target at 800 instead of 950). Don't override in code; override in config.
 - **Custom gate-implementations**: for organisation-specific gates (e.g., "all images must be optimised"), add them as `presets/<use-case>.yaml` `custom_gates:` entries pointing at a node-script that returns `{name, pass, output}`. Skill calls the script as if it were a built-in gate.
 - **Quick-vs-final composition**: extend the gate-table with a `mode` column listing `quick` / `final` / `both`. The CLI flag selects which subset runs.