fdeops 3.5.0

package/skills/fde/references/qa-live.md

@@ -0,0 +1,113 @@
+# qa-live - test it like a user, not like an engineer
+
+**Enter when:** a feature is built and needs to be verified from the user's perspective, the team says "it works on my machine," a demo is coming and the feature hasn't been clicked through, or a post-deploy smoke test is needed.
+
+**Read first:** `delivery.md` (what was built), `decisions.md` (acceptance criteria), `success.md` (what the customer expects to see), `context.md`.
+
+Unit tests prove the code works. QA proves the *feature* works - from the user's chair, on a real browser, with real data patterns. The FDE who ships a feature that passes all tests but fails the first user click has shipped a defect.
+
+## Method (you do this work)
+
+**1. Write the test script from the user's story, not the code.**
+
+Start with `success.md` and `decisions.md` acceptance criteria. For each acceptance criterion, write the human steps:
+
+```markdown
+## Test: User can retry a failed payment
+Precondition: User has a failed payment in their history
+Steps:
+  1. Navigate to payment history
+  2. Click the failed payment
+  3. Click "Retry payment"
+  4. Confirm the retry dialog
+  5. Observe the result
+Expected: Payment processes successfully, status updates to "Completed"
+Also check: Error message if retry fails, loading state during processing
+```
+
+**2. The five perspectives.** Test each feature from five angles that unit tests can't reach:
+
+| Perspective | What to test | Common FDE finding |
+|------------|-------------|-------------------|
+| **Happy path** | Does the main flow work end-to-end? | Works locally, fails with real data volumes |
+| **Error path** | What happens when things go wrong? | Error messages are developer-facing, not user-facing |
+| **Edge cases** | Empty states, max lengths, special characters, concurrent users | The empty state shows "undefined" instead of a helpful message |
+| **Performance** | Is it fast enough for real use? | Works fine with 10 records, unusable with 10,000 |
+| **Accessibility** | Can it be used with keyboard only? Does the screen reader make sense? | Tab order is broken, focus traps in modals |
+
+**3. Real browser testing.** Open the actual application in a browser and click through:
+
+```
+Before each test:
+  - Clear relevant caches/state
+  - Use realistic test data (not "test test test")
+  - Note the browser and viewport size
+
+During each test:
+  - Open DevTools console - watch for errors
+  - Open DevTools network tab - watch for failed requests
+  - Time the critical actions (user-perceivable latency)
+
+After each test:
+  - Screenshot the result (before/after when relevant)
+  - Note any console errors even if the test "passed"
+  - Note any UX friction even if technically correct
+```
+
+**4. The health score.** Rate the feature across five dimensions, 1–5:
+
+| Dimension | 1 (broken) | 3 (acceptable) | 5 (polished) |
+|-----------|-----------|----------------|--------------|
+| **Functionality** | Critical path fails | Happy path works, errors unhandled | All paths work, errors graceful |
+| **Performance** | >5s load time | <2s load time | <500ms load time, no layout shifts |
+| **Error handling** | Crashes or shows stack trace | Shows error message | Shows actionable error with recovery option |
+| **Data handling** | Corrupts or loses data | Handles normal data correctly | Handles edge cases (empty, large, special chars) |
+| **User experience** | Confusing or broken layout | Functional but rough | Intuitive, consistent with the rest of the app |
+
+**Overall health = average of five scores.** Below 3.0 → not ready to ship. 3.0–4.0 → shippable with known issues. 4.0+ → confident to demo.
+
+**5. The bug report format.** For each issue found:
+
+```markdown
+## Bug: <one-line summary>
+Severity: critical / high / medium / low
+Steps to reproduce:
+  1. <exact steps>
+  2. <exact steps>
+Expected: <what should happen>
+Actual: <what happened>
+Evidence: <screenshot, console error, network request>
+Environment: <browser, viewport, data state>
+```
+
+**6. Re-verify after fixes.** After each bug is fixed:
+- Re-run the exact reproduction steps
+- Check that the fix didn't break adjacent functionality
+- Update the health score
+- Screenshot the fixed state
+
+## Artifact
+
+**`delivery.md`** - the health score and test results for each shipped feature:
+```markdown
+## QA: <feature name> - <date>
+Health score: 4.2 / 5.0
+Tests run: 8 passed, 1 failed (fixed), 1 known issue (low severity)
+Bugs found: 2 (1 fixed, 1 deferred to next sprint)
+Ready to demo: YES / NO
+```
+
+**`decisions.md`** - bugs deferred with rationale (why it's acceptable to ship with this known issue).
+
+## Checkpoint
+
+One line: "Feature tested from user perspective. Health score: <N>/5. <N> bugs found, <N> fixed, <N> deferred. Ready to demo: yes/no." If not ready: the specific blocker.
+
+## Principles
+
+- Test from the user's chair, not the developer's IDE.
+- Real browser, real data patterns, real network conditions.
+- Console errors during a "passing" test are still findings.
+- Health score below 3.0 = not ready to ship, regardless of test suite.
+- Every bug gets a reproduction recipe, not a description.
+- A feature that passes all unit tests but fails the first click is a defect.

package/skills/fde/references/rescue.md

@@ -0,0 +1,81 @@
+# rescue - production fire, trust fire, or wrong-brief mid-build
+
+**Enter when:** production is down, something's bleeding - OR a stakeholder went quiet, confidence is slipping, or three weeks into the build the brief turned out to be wrong. Trust fires get the same urgency as outages.
+
+**Read first:** `context.md`, `risks.md` only. Pull specific module context only once you know what you're looking at.
+
+First move - one disambiguator if unclear: **"Is production broken right now, or is this a trust/alignment problem?"**
+
+## A. Technical fire (you do this work)
+
+Open by narrowing time, like a human: "Walk me through the last couple hours - deploys, config, anything that moved." Something always changed; "nothing changed" means nobody's looked:
+```bash
+git log --since="6 hours ago" --format="%ad %an %s" --date=relative
+```
+
+**The sequence:**
+1. **Stabilise first.** Roll back? Disable the broken path? Route around it? Buy time before diagnosing. The instinct to fix fast causes the second incident.
+2. **Name the unknowns.** "We don't know if the queue is corrupted / if this hits all users / if the cache is stale." Written down. Named unknowns are safer than assumed knowns.
+3. **Assume maximum blast radius.** The unrecognised integration in the stack trace is load-bearing until proven otherwise.
+4. **Minimum safe change.** Often a read-only query first - observe before acting. Never two changes at once: if the problem disappears you won't know which one fixed it, and that matters at 3am when it returns.
+5. **One hypothesis at a time.** "If X, then Y should produce Z." Test, document, next.
+6. **Instrument before touching.** A change without observability is a change without evidence.
+
+**Tell the FDE three things, nothing else** (they need to act): what to do right now to stop it worsening · most likely cause on current evidence · what must not be touched yet.
+
+## B. Trust fire (you coach - calm, no panic coding)
+
+**Signals:** a stakeholder stops responding or routes around the FDE · meetings shorten, decisions defer · "is the timeline still realistic?" with no follow-up · a decision-maker never met starts asking about the work.
+
+**The read:** the stakeholder who goes quiet is not losing interest - **they are escalating above you.** Roughly 48 hours before someone you've never met decides about the engagement. Respond same-day.
+
+**The move:** do NOT push harder on delivery - more commits won't warm a cold sponsor. A real conversation: curious, not defensive; hear the concern, don't explain it away. Offer the FDE wording in their own voice - checking alignment, asking what changed in expectations, naming one underestimated thing without drama. Recovery = honesty + a short dated recovery path + one visible win before the next exec touchpoint. Log what was said and agreed in `decisions.md` before the day ends.
+
+## C. Wrong brief, mid-build
+
+The most politically dangerous moment in FDE work: visible progress toward the wrong thing. Never absorb it silently.
+
+1. **Stop the work.** Every further line builds on a known-wrong foundation.
+2. **Write the evidence, not the interpretation.** The traced data flow, the schema that contradicts the API contract, the workaround nobody mentioned.
+3. **Conversation before the day ends.** Not email: "We need twenty minutes. We found something important." Waiting reads as concealment.
+4. **Evidence before recommendations.** A customer who reaches the conclusion themselves owns the reset.
+5. **Three paths, never one:** descope (deliver something real within the original brief) / rescope (real problem, revised timeline) / pause-and-plan. One path is permission-seeking; three is a conversation between professionals.
+6. **Reset in writing** - update `success.md` and `reality.md`, get explicit acknowledgement - before building resumes.
+
+Customers remember who told them the truth before it cost them money.
+
+## D. Pivot - the whole direction changed
+
+Not scope-defense (that's someone adding). This is: budget cut, new CTO arrives, strategic priority shift, acquisition changes everything, "we've decided to go a different direction." The engagement's foundation moved.
+
+**Signals:** new leadership asks "why are we doing this?", the sponsor's boss questions ROI, a competing initiative gets the resources, the quarterly priorities deck doesn't mention your project, the team you're embedded in gets reorganized.
+
+**The pivot protocol:**
+1. **Acknowledge immediately.** Don't pretend the old brief still applies. "The context has changed - let's make sure we're building toward the new reality."
+2. **Protect what's already delivered.** Shipped value is not un-shipped by a pivot. Name it: "Here's what's live and working. That value is real regardless of direction."
+3. **Assess salvageability.** What from the current work applies to the new direction? What's dead? What can be repurposed? Present this honestly - don't stretch to make everything fit.
+4. **Three paths (same pattern as wrong-brief):**
+   - **Redirect** - current work pivots to serve the new priority (minimal waste).
+   - **Pause** - freeze current scope, start fresh discovery on new direction.
+   - **Graceful close** - deliver what's done, document everything, hand off cleanly.
+5. **Reset the artifacts.** Update `success.md` (new definition of success), `reality.md` (new context), `brief.md` (new direction). The old versions stay in git history - the FDE can reference "here's what we were solving before, here's what changed."
+6. **Re-earn trust fast.** A pivot is a trust moment. The FDE who smoothly redirects gains credibility. The FDE who fights the pivot or pretends nothing changed loses it. Deliver one visible win in the new direction within the first week.
+
+**Commercial awareness:** A pivot may change the SOW. Surface this to whoever owns commercials: "The scope has changed materially - does the contract need updating?" Don't assume; don't ignore.
+
+## Artifact
+
+**`chaos-log.md`** - written in the 30 minutes after resolution (memory decays fast): what happened, what changed, hypotheses in order, the fix, the learning. **`risks.md`** - new risks the crisis revealed. **`decisions.md`** - trust-fire conversations, agreements, and pivot decisions. Update `reality.md`/`terrain.md` if the crisis or pivot disproved them.
+
+## Checkpoint
+
+Stable + log written + one question answered with the FDE: does this change what we thought we knew? If yes, the relevant artifact gets updated now, not "later."
+
+## Principles
+
+- Stabilise before diagnosing.
+- Named unknowns beat assumed knowns. Minimum safe change, one hypothesis.
+- Never production without a tested rollback - even in a crisis.
+- A trust fire is a same-day fire.
+- The chaos log is written before the day ends.
+- A pivot is a trust moment - redirect smoothly, don't fight the new reality.

package/skills/fde/references/review.md

@@ -0,0 +1,53 @@
+# review - two stages, always in order
+
+**Enter when:** a change needs review before merge - "is this safe," "does it match what we agreed."
+
+**Read first:** `context.md`, `decisions.md`, `trust-profile.md`, `terrain.md`. Not `reality.md`/`stakeholders.md` - irrelevant to reviewing code against agreed scope.
+
+Engagement review ≠ product-company review: a codebase you don't own, systems you can't fully see, a customer who can't afford a bad release.
+
+## Pre-flight: is this reviewable?
+
+Thousands of lines or dozens of unrelated files → **stop**, recommend the split in `decisions.md`, route to plan. Review loops fail on huge diffs. Ask: one agreed task, or did scope merge mid-build?
+
+## Stage 1 - did we build what we agreed? (you do this work)
+
+Check the diff against `decisions.md` - what was *explicitly decided*, not what seems right:
+- Matches agreed scope?
+- Any sacred system from `trust-profile.md` touched?
+- Any sensitive data newly in scope?
+- Rollback path defined before build still honoured?
+
+**Stage 1 fails → stop.** Quality review on out-of-scope code is wasted work. Record the specific mismatch in `decisions.md`.
+
+## Stage 2 - is it safe to live with?
+
+Five dimensions, line-specific ("line 47 fails under concurrent writes - no lock"), never "could be better":
+
+- **Correctness** - does what it says; edge cases; error paths traced.
+- **Blast radius** - what breaks at 2am; downstream systems; failure mode loud (errors surface) or silent (data corrupts over time)?
+- **Security** - input validation at boundaries; no secrets in logs; no new attack surface; `trust-profile.md` sensitivity classes respected.
+- **Rollback** - revertible in under 5 minutes, documented? "We'd need a data migration to roll back" is a blocker.
+- **AI policy & components** - human-review requirements honoured; model output treated as untrusted until validated; fallback exists; inputs/outputs logged; outputs bounded so a hallucination can't cascade; in regulated environments a human can explain why the AI decided X (compliance requirement, not preference).
+
+**Structural pass on AI-heavy or data-touching changes:** migrations reversible · destructive SQL guarded · PII/PCI/PHI paths match `trust-profile.md` · side effects (flags, webhooks, emails, jobs) fire only when intended · magic strings that break on rename · new behaviour has a test or an explicit reason it can't yet. One line problem, one line fix.
+
+## The review-fix loop (until clean)
+
+1. Read the full diff before commenting.
+2. Verdicts: **Stage 1: Pass / Blocked (reason)** · **Stage 2: Pass / Concerns (line-specific)**.
+3. Fix only **real** findings tied to this change - no drive-by refactors. Reject false positives with one sentence why.
+4. Add or update a test per bug found where possible.
+5. Re-run tests/typechecks - state what ran.
+6. Re-review. Repeat until Pass/Pass or a human must decide scope/product.
+
+## Artifact
+
+**`decisions.md`** - each cycle logged: what was reviewed, flagged, fixed, verified. Stage 1 failures recorded with the specific mismatch.
+
+## Principles
+
+- Stage 1 before Stage 2. Wrong scope reviewed well is still wrong scope.
+- Specific or silent - vague concerns waste everyone's time.
+- No rollback path = first finding.
+- A clean review proves this diff is safe as agreed - not that the feature was right.

package/skills/fde/references/rollback-drill.md

@@ -0,0 +1,102 @@
+# rollback-drill - test the escape route before you need it
+
+**Enter when:** a deploy is planned for the next 48 hours, the FDE says "we can always revert," a previous rollback failed or took too long, or the engagement involves regulated/critical systems.
+
+**Read first:** `delivery.md` (the deployment record), `terrain.md`, `trust-profile.md` (for change-approval requirements), `context.md`.
+
+"We can always revert" is the most dangerous sentence in deployment. A rollback plan that hasn't been tested is a wish, not a plan. The drill proves the escape route works before you need it at 2am.
+
+## Method (you do this work)
+
+**1. Map the rollback path for every change type:**
+
+| Change type | Rollback method | Complication | Test |
+|-------------|----------------|--------------|------|
+| **Code deploy** | Revert the PR / redeploy previous version | Feature flags, cache invalidation | Deploy previous version to staging, verify function |
+| **Database migration** | Down migration script | Irreversible migrations (column drops, data transforms) | Run down migration on staging copy |
+| **Config change** | Restore previous config | Propagation delay, dependent service restarts | Flip config, verify all services pick it up |
+| **Infrastructure** | Terraform/Pulumi rollback or manual | State drift, dependent resources | Plan the rollback, review the diff |
+| **Data backfill** | Restore from backup or reverse script | Mixed old/new data states | Run reverse on a 100-row sample |
+
+**2. Identify the irreversible components.** Some changes can't be rolled back:
+
+- Column drops after data migration
+- Encryption key rotations after old key is destroyed
+- External API version deprecations
+- Emails/notifications already sent
+- Published API changes consumed by third parties
+
+For each irreversible component: **what's the compensating action?** Not "undo" but "what do we do to recover the same effect?"
+
+**3. Run the drill.** On staging or a test environment - never on production:
+
+```
+DRILL PROTOCOL:
+1. Deploy the change (confirm it works)
+2. Start a timer
+3. Execute the documented rollback procedure - exactly as written, no shortcuts
+4. Measure: time to complete, services affected, data state after
+5. Verify: can users still do the critical path?
+6. Record: what worked, what was unclear, what failed
+```
+
+**4. The drill report.** Honest, specific, actionable:
+
+```markdown
+## Rollback drill - <date>
+Change: <what was deployed>
+Environment: staging
+Rollback method: <what was executed>
+Time to rollback: <minutes:seconds>
+Result: PASS / FAIL / PARTIAL
+
+What worked:
+- Code revert completed in 45s
+- Feature flag disabled correctly
+
+What didn't:
+- Database down migration left orphan rows in junction table
+- Cache took 3 minutes to invalidate (stale data served)
+
+Actions before production deploy:
+- [ ] Fix down migration to clean junction table
+- [ ] Add cache-bust step to rollback procedure
+- [ ] Verify cache invalidation time is acceptable
+```
+
+**5. The "acceptable rollback time" conversation.** With the FDE and the team:
+
+> "If this deploy fails in production, how long can the system be in a degraded state before it's a business problem?"
+
+| Answer | Implication |
+|--------|-------------|
+| "Minutes" | Automated rollback trigger needed - human decision loop is too slow |
+| "An hour" | Manual rollback is acceptable if the procedure is tested and documented |
+| "A day" | Gradual rollback is fine - feature flag off, monitor, clean up next morning |
+| "It can't fail" | Blue/green deployment with instant traffic switch - test both environments |
+
+**6. Change-approval environments (CAB).** In regulated industries:
+
+- The rollback procedure is part of the change ticket - filed before the approval window.
+- The drill evidence goes with the change request: "Rollback tested on <date>, completed in <time>, no issues."
+- A drill that fails → the change ticket isn't ready. Better to discover that now than during the CAB.
+
+## Artifact
+
+**`delivery.md`** - the drill report, attached to the deployment record for this change. The evidence that the rollback works.
+
+**`risks.md`** - any irreversible components identified, with the compensating action.
+
+**`decisions.md`** - if the drill failed and the deployment is delayed: what failed, the fix, the revised timeline.
+
+## Checkpoint
+
+One statement: "Rollback tested on staging. Time: <N minutes>. Result: <pass/fail>. Production deploy is / is not ready." If not ready: the specific blocker and when it'll be resolved.
+
+## Principles
+
+- A rollback plan that hasn't been tested is a wish.
+- Time the drill. If it takes 45 minutes on staging, it takes 90 in production at 2am.
+- Identify the irreversible components and name the compensating action.
+- The drill report is evidence for the change ticket and the team's confidence.
+- A drill that fails is a success - you found the problem before production did.

package/skills/fde/references/scope-defense.md

@@ -0,0 +1,71 @@
+# scope-defense - holding the line without losing the relationship
+
+**Enter when:** "also can you…" mid-build, a stakeholder adds requirements without adjusting timeline, the FDE feels scope creeping but can't name it, or `success.md` no longer matches what's being asked.
+
+**Read first:** `success.md` (the agreed boundary), `decisions.md`, `context.md`. Load `stakeholders.md` to know who's asking and their signal.
+
+Scope creep is the leading cause of FDE engagement failure - not technical complexity, not timeline pressure. It's silent: no single request feels unreasonable, but twenty reasonable requests add three months. The skill is saying "that's phase two" without the customer hearing "no."
+
+## Method (you do this work)
+
+**1. Detect before it compounds.** Three patterns that signal creep before it's named:
+
+| Pattern | What it sounds like | What's actually happening |
+|---------|--------------------|--------------------------| 
+| **The friendly addition** | "While you're in there, could you also…" | Adjacent work getting absorbed without timeline adjustment |
+| **The evolved requirement** | "Oh, what I actually meant was…" | The original scope was never clear enough - `success.md` needs updating |
+| **The stakeholder swap** | A new person starts requesting features the original sponsor didn't | Power shifted; the real scope is being rewritten informally |
+
+**2. The scope receipt.** Every request gets logged with its origin and cost - not as bureaucracy, but as evidence for the conversation that's coming:
+
+```markdown
+## Scope change - <date>
+Requested by: <who>
+Request: <what, in their words>
+Impact: <hours/days added, what gets pushed>
+Status: absorbed / deferred to phase 2 / needs conversation
+```
+
+Log via `fde log decision "scope change: <summary> - requested by <who>, impact: <estimate>"` or direct append to `decisions.md`.
+
+**3. The three-bucket response.** Never say "no" - say "here's where it fits":
+
+| Bucket | What you say | When to use |
+|--------|-------------|-------------|
+| **This phase** | "That fits - I'll add it to the current plan. Timeline stays the same." | The request is small and genuinely within the agreed scope |
+| **Next phase** | "That's real - let me capture it properly so it doesn't get lost. It's phase-two work because <reason>." | The request is valid but adds to the timeline |
+| **Separate engagement** | "That's a different problem - it deserves its own brief and its own timeline." | The request is a new project wearing a small-ask costume |
+
+**The key phrase: "Let me place it."** Not "that's out of scope" (adversarial) or "sure" (absorbed). "Let me place it" signals you're taking it seriously while buying time to assess the real cost.
+
+**4. The accumulation conversation.** When the scope receipts show a pattern - typically 3–5 absorbed changes - the FDE needs a conversation with the sponsor:
+
+Frame it as **protection, not complaint:**
+> "We've absorbed five changes since the original agreement. Each one made sense individually. Together, they've added roughly two weeks. I want to make sure the timeline expectation still matches - should we adjust the delivery date, or reprioritise to keep the original date?"
+
+Evidence-based: point to `decisions.md` scope receipts with dates and requesters. The sponsor who sees the pattern is an ally; the sponsor who discovers the delay at the end is a problem.
+
+**5. The commercial boundary.** In paid engagements, scope creep silently moves billing and liability:
+
+- If the engagement is time-and-materials: scope creep is the client's money, but flag it - they deserve to know what they're buying.
+- If the engagement is fixed-price: every absorbed scope change is a gift the FDE's company didn't agree to. Surface it to whoever owns the commercials.
+- If the engagement has a success fee: scope changes that move the success criteria affect compensation. Log it.
+
+## Artifact
+
+**`decisions.md`** - scope receipts, dated and attributed. The running record the accumulation conversation references.
+
+**`success.md`** - updated ONLY when a scope change is explicitly agreed. Never silently expanded. Each update: what changed, who agreed, date.
+
+## Checkpoint
+
+Weekly check: count the scope receipts since last conversation. Three or more unaddressed → recommend the accumulation conversation to the FDE. Zero → "scope holding, `success.md` current."
+
+## Principles
+
+- "Let me place it" is the phrase. Not "no," not "sure."
+- Every scope change gets a receipt. The receipt is the evidence.
+- Three unaddressed scope changes → accumulation conversation.
+- Scope creep kills engagements that technical failure couldn't.
+- `success.md` is a contract - update it explicitly or defend it.
+- The FDE who absorbs everything is liked for three weeks and blamed for three months.

package/skills/fde/references/security-audit.md

@@ -0,0 +1,105 @@
+# security-audit - find the holes before someone else does
+
+**Enter when:** the engagement touches auth, payments, user data, or external integrations; the customer mentions compliance (SOC2, PCI, HIPAA); a new API endpoint is being shipped; or the FDE is asked "is this secure?"
+
+**Read first:** `trust-profile.md` (data classification, AI policy, compliance requirements), `terrain.md`, `context.md`. Load the relevant regulated overlay (fintech/healthcare/gov) if the signal is present.
+
+On an FDE engagement, security mistakes are twice as dangerous: you break someone else's system, with their users' data, under their compliance obligations. The FDE who finds the vulnerability before production earns trust that lasts the entire engagement.
+
+## Method (you do this work)
+
+**1. Threat model in five minutes.** Not a ceremony - five questions before looking at code:
+
+| Question | What it reveals |
+|----------|----------------|
+| Where does untrusted data enter? | HTTP requests, file uploads, webhooks, LLM outputs, message queues |
+| What's worth stealing? | Credentials, PII, payment data, API keys, session tokens |
+| What's worth breaking? | Auth system, payment flow, admin actions, data integrity |
+| Who's the attacker? | External (internet), internal (employee), adjacent (other tenant), automated (bot) |
+| What's the worst realistic outcome? | Data breach, financial loss, regulatory fine, reputation damage |
+
+Write the answers before scanning code. The threat model tells you where to look; code scanning without a threat model is reading every room in a building instead of checking the doors.
+
+**2. The STRIDE pass.** For each trust boundary (where data crosses from untrusted to trusted):
+
+| Threat | Check | Common FDE finding |
+|--------|-------|-------------------|
+| **Spoofing** | Can someone impersonate a user/service? | Missing auth on internal endpoints ("it's behind the VPN" is not auth) |
+| **Tampering** | Can data be altered in transit or at rest? | Unparameterised SQL, unsigned webhooks, client-side validation as sole gate |
+| **Repudiation** | Can an action be denied later? | No audit log on admin actions, no timestamp on state changes |
+| **Information disclosure** | Can data leak? | Stack traces in production errors, PII in logs, verbose error messages |
+| **Denial of service** | Can it be overwhelmed? | No rate limiting on auth endpoints, unbounded file uploads, no pagination |
+| **Elevation of privilege** | Can a user gain access they shouldn't? | IDOR (changing user ID in URL), missing role checks on endpoints |
+
+**3. The automated scan.** Run these - they catch what manual review misses:
+
+```bash
+# Secrets in code (repeat --include per extension)
+grep -rnE "(api[_-]?key|secret|password|token|private[_-]?key)\s*[:=]\s*['\"][^'\"]{8,}" \
+  --include="*.js" --include="*.ts" --include="*.py" --include="*.env" \
+  --include="*.yaml" --include="*.json" . | grep -vE "example|template|test|mock" | head -20
+
+# Dependency vulnerabilities
+npm audit 2>/dev/null || pip audit 2>/dev/null || echo "no package audit available"
+
+# SQL injection patterns
+grep -rnE "(SELECT|INSERT|UPDATE|DELETE).*\+.*\"|f['\"].*{.*}.*SELECT" \
+  --include="*.js" --include="*.ts" --include="*.py" . | head -10
+
+# Dangerous patterns
+grep -rnE "eval\(|innerHTML\s*=|document\.write\(|exec\(|__import__" \
+  --include="*.js" --include="*.ts" --include="*.py" . | head -10
+```
+
+**4. The AI security check.** If the system uses AI/LLM components:
+
+| Check | Finding if yes |
+|-------|---------------|
+| Is model output used in SQL, shell commands, or HTML without sanitisation? | Injection via prompt - treat model output as untrusted input |
+| Is the system prompt relied on as a security boundary? | Prompt injection bypasses it - enforce permissions in code |
+| Are secrets or cross-tenant data in the context window? | Data leakage via prompt extraction |
+| Are tool/agent permissions scoped? | Excessive agency - model can take actions it shouldn't |
+| Are token/rate/recursion limits set? | Unbounded consumption or infinite loops |
+
+**5. Classify findings by severity and action:**
+
+| Severity | Criteria | Action |
+|----------|----------|--------|
+| **Critical** | Exploitable now, real data at risk | Stop other work. Fix before next merge. |
+| **High** | Exploitable with effort, or compliance violation | Fix this phase. Track in `risks.md`. |
+| **Medium** | Defense-in-depth gap, no immediate exploit | Log it. Fix when the module is next touched. |
+| **Low** | Best practice gap, no exploit path | Note for the handoff document. |
+
+**6. Present findings as protection, not criticism.**
+
+The internal team built this system under constraints. Frame findings as shared wins:
+
+> "Found three endpoints without rate limiting - adding that now prevents the bot attack that hit [company in their industry] last quarter. Here's the fix."
+
+Not: "Your auth is broken." Even if it is.
+
+## Artifact
+
+**`risks.md`** - each finding with severity, evidence, remediation, and status:
+```markdown
+## Security finding: <title> - <severity>
+Where: <file:line or endpoint>
+Evidence: <what you found>
+Risk: <what an attacker could do>
+Remediation: <specific fix>
+Status: fixed / in-progress / logged-for-handoff
+```
+
+**`trust-profile.md`** - update if new sensitive data paths, AI components, or compliance requirements were discovered.
+
+## Checkpoint
+
+Summary to the FDE: findings by severity count, the one critical/high finding that needs immediate attention (if any), and the overall security posture in one sentence. If no critical findings: "No exploitable issues found in this pass - next audit at <trigger>."
+
+## Principles
+
+- Threat model first, scan second. Know where to look before looking everywhere.
+- Treat model output as untrusted input - always.
+- Frame findings as protection, not criticism. The team built under constraints.
+- Secrets in code outrank every other finding. Check first.
+- A security audit with no findings either found nothing or didn't look hard enough - state which.

package/skills/fde/references/ship.md

@@ -0,0 +1,121 @@
+# ship - production without surprises
+
+**Enter when:** a slice is built, reviewed, and ready to deploy.
+
+**Read first:** `context.md`, `delivery.md`. Load `trust-profile.md` if the deploy touches regulated data or needs an approval chain.
+
+Opening question, calm tech lead voice: **has anyone actually *run* the rollback, or is it still a slide?** If only planned, that's today's work - say so plainly.
+
+## Method - readiness gate (score before touching the deploy button)
+
+Score each dimension green/amber/red. This is the gate, not a suggestion:
+
+| Dimension | Green | Amber | Red |
+|-----------|-------|-------|-----|
+| Tests | All pass on deploy branch | Flaky tests skipped with justification | Failures present or tests not run |
+| Rollback | Tested end-to-end (not planned - TESTED) | Documented but untested | No rollback path defined |
+| Sign-off | Stakeholder approval in `decisions.md` with date | Verbal approval, not logged | No approval sought |
+| Runbook | Exists and someone other than you has read it | Exists but unreviewed | Missing |
+| Monitoring | Alerts configured, owner named, dashboard live | Alerts configured, no named owner | No monitoring |
+
+**Any RED = stop. Do not deploy. Fix the red dimension first.**
+**2+ AMBER = sponsor conversation before deploying.** Present the ambers and get explicit "proceed" or "fix first."
+
+Write the readiness score to `delivery.md` before deploying. The score is the evidence if anything goes wrong.
+
+## Method - pre-flight (you verify each, confirmed not assumed)
+
+- All tests pass - state the command and result.
+- No hardcoded secrets/credentials (repeat `--include` per extension - brace globs silently match nothing):
+```bash
+grep -rnE "(api[_-]?key|secret|password|token)\s*[:=]\s*['\"][^'\"]{8,}" \
+  --include="*.js" --include="*.ts" --include="*.py" --include="*.env" \
+  --include="*.yaml" --include="*.json" . | grep -vE "example|template|test" | head
+```
+- DB migrations reversible.
+- Rollback documented **and tested**.
+- Monitoring alerts configured, someone watching.
+- Team knows the deploy is happening.
+- Not a Friday unless genuine emergency with someone on call.
+- **Change approval (CAB) environments:** window open, ticket approved. In banking/healthcare/gov, deploying outside an approved window is a compliance finding even when the deploy succeeds. "We didn't know there was a CAB process" is not a defence - find out before the deploy date.
+
+## Method - the deploy
+
+**Canary:** 1–5% of traffic, ≥10 minutes. Watch error rate, latency, and **the business metric this change affects**. Anything looks wrong → roll back immediately; investigate safely; redeploy when confident. Never investigate during the canary. Then stage up: 5% → 25% → 100%, each confirmed stable.
+
+**Programme-scale rollout (transformations)** - different problem from one service:
+1. **Pilot** - one team, one use case; success metrics defined *before* it starts (after = fitting metrics to results).
+2. **Limited release** - 3–5 teams, real load; this is where the failure modes the pilot hid show up.
+3. **Broad release** - self-serve onboarding; if teams still need the FDE to start, onboarding isn't finished.
+4. **Enterprise standard** - the FDE is no longer needed for this use case. That's the end state.
+Straight from pilot to standard = a high-profile failure at scale.
+
+## Method - after
+
+Smoke tests against production. Verify the business metric moved the right way. Then **define the pulse before closing the laptop** - a deploy without a pulse is one you'll hear about only when it breaks:
+
+1. **Metric:** the number that says it's working - "p99 on payment endpoint < 800ms", not "errors low."
+2. **Frequency:** daily week one, weekly after, monthly when stable.
+3. **Threshold:** the exact value that triggers incident response. Nobody knows the number → nobody acts until too late.
+
+AI components: also define what *normal output* looks like and check a weekly sample of real production outputs - drift is technically-valid-but-wrong, and no exception will fire.
+
+## Method - scale readiness (pilot proved it, now deploy enterprise-wide)
+
+95% of AI pilots fail to reach production. The gap isn't technical - it's organizational, governance, and infrastructure readiness. This checklist determines whether the pilot is ready to scale.
+
+**The scale-readiness gate (all must be YES before broad rollout):**
+
+| Dimension | Question | Ready? |
+|-----------|----------|--------|
+| **Infra** | Can the system handle 10× current load without architectural change? | |
+| **Ops** | Can someone other than the FDE operate it at 2am? (runbook exists, tested) | |
+| **Data** | Is the data pipeline automated, not manual? Does it handle upstream schema changes? | |
+| **Security** | Has infosec signed off for production data at scale? | |
+| **Cost** | Is the cost model viable at 10× volume? (AI inference costs scale non-linearly) | |
+| **Governance** | Is there an owner, a review cadence, and an escalation path? | |
+| **Support** | Can users get help without the FDE? (docs, training, L1 support path) | |
+| **Measurement** | Are success metrics automated and dashboarded, not manually calculated? | |
+
+**If any dimension is "No":** that's the work before scaling. Name it, size it, put it in the plan. Scaling without readiness = a high-profile failure that kills the entire programme.
+
+**The scale sequence:**
+1. **Pilot** (1 team, controlled) → prove value, find failure modes
+2. **Limited** (3–5 teams, real load) → prove operability, find scale bugs
+3. **Broad** (self-serve onboarding) → prove the team doesn't need the FDE
+4. **Standard** (enterprise default) → the FDE exits this workstream
+
+Never skip a step. The sponsor always wants to skip from pilot to standard - that's the conversation the FDE protects.
+
+## Method - progressive adoption (built it, now people need to use it)
+
+Adoption isn't a handoff-stage problem - it starts during build. Software that launches to silence is software that gets decommissioned.
+
+**During build:**
+- **Feature flags from day one.** Every new capability behind a flag. Ship to 5% of users first. Watch behavior before opening to 100%.
+- **Feedback loops built in.** A thumbs-up/down, a "was this helpful?", a usage counter. Instrument adoption, don't assume it.
+- **Resistance signals.** Watch for: workaround creation (they built a spreadsheet instead of using the tool), drop-off after day 3 (onboarding fails), vocal detractors (one influential skeptic can kill adoption). Address these DURING build, not after launch.
+
+**At launch:**
+- **Champion network.** Identify 2–3 power users per team who adopt early. Support them intensely - they become your multiplier.
+- **30-60-90 adoption targets.** Week 1: 20% of target users try it. Week 4: 50% use it weekly. Week 12: 80% can't imagine working without it. If week 1 misses → the onboarding is broken. If week 4 misses → the value proposition is wrong.
+- **The "switching cost" test.** If users can still do it the old way, they will. Adoption requires either: the old way is removed, the new way is dramatically better, or management mandates the switch. Know which lever applies.
+
+**Write adoption metrics to `delivery.md`:** active users, frequency, drop-off points, resistance signals. This is the evidence for renewal.
+
+## Artifact
+
+**`delivery.md`** - deployment record: what shipped, when, what it delivers in business terms, rollback procedure, pulse definition, **scale-readiness assessment, and adoption metrics**. Written for whoever inherits the system.
+
+## Checkpoint
+
+Before 100%: canary clean, business metric verified, pulse written into `delivery.md`. Any item unconfirmed → the deploy waits. For enterprise-scale: scale-readiness gate passed before broad rollout.
+
+## Principles
+
+- A deployment without a tested rollback is reckless.
+- Roll back on any canary anomaly; investigate safely.
+- Verify the business metric, not just the technical one.
+- No pulse, no done.
+- Scale readiness is organizational, not just technical. Check all 8 dimensions.
+- Adoption is measured from day one, not hoped for at launch.