@kensaurus/skills 0.0.0-stage → 2.1.0

package/skills/workflow-refactor/SKILL.md

@@ -0,0 +1,274 @@
+---
+name: workflow-refactor
+description: >
+  Scoped, behavior-preserving refactor: map dependencies, change structure,
+  run affected tests. Use when "refactor this", "reduce duplication", or
+  "improve readability". Dead code → plan-dead-code. Repo-wide smells →
+  audit-code-quality.
+license: MIT
+---
+
+# Refactor Code Skill
+
+**Degree of freedom: MIXED.** Structure target `[HIGH freedom]`;
+behavior-preserving checks and affected tests `[LOW freedom — run exactly]`.
+
+## How to reason
+
+1. **Observe** — current structure, callers, tests
+2. **Interpret** — duplication vs needed variation
+3. **Classify** — extract / inline / rename / stop (behavior would change)
+4. **Severity** — a public API change is not this skill
+
+Everything here **preserves behavior**. Removing code is a different
+contract: `plan-dead-code` proves it unreachable and `housekeep-dead-code`
+deletes it against an approved list. Duplication findings arrive here from
+those skills; deletions do not leave from here.
+
+## Worked example
+
+> **Observe:** three copy-pasted date formatters; tests only cover one.
+> **Interpret:** same behavior, three implementations.
+> **Classify:** extract `formatDate`; add the missing two call-site tests first (red), then extract (green).
+> **Verify:** same output; no new features.
+
+## Self-critique before reporting
+
+- **Behavior same** — existing tests still pass; no silent product change
+- **Scoped** — not a repo-wide drive-by
+- **Tests first** — missing coverage added before the move when needed
+- **Right owner** — repo-wide anti-pattern → `audit-code-quality`; mechanical rename → `burndown-full`
+
+Improve code quality without changing external behavior. Research-aware.
+
+## Pre-refactoring checks  [LOW freedom — run exactly]
+
+**Before refactoring any code:**
+
+### 1. Read Relevant Documentation
+```
+README.md (project overview)
+src/[domain]/@_[domain]-README.md (domain architecture)
+CONTRIBUTING.md (code standards)
+```
+
+### 2. Understand Existing Patterns
+
+Use `Grep` and `SemanticSearch` to find:
+- How similar code is structured elsewhere in the codebase
+- What patterns are already established
+- Every file that imports or depends on the code being refactored
+
+### 3. Map the Blast Radius
+
+Before changing any function, class, or component:
+```bash
+rg "functionName" --type ts # find all callers
+rg "import.*from.*module" --type ts # find all importers
+```
+
+List every file that will be affected by the change.
+
+### 4. Research Modern Patterns (for non-trivial refactors)
+
+If the refactoring introduces a new pattern, verify it's current best practice:
+
+```json
+firecrawl:firecrawl_search
+{
+ "query": "<framework> <pattern> best practice <current year>",
+ "limit": 5,
+ "sources": [{ "type": "web" }]
+}
+```
+
+Scrape the most authoritative result:
+
+```json
+firecrawl:firecrawl_scrape
+{
+ "url": "<best-result-url>",
+ "formats": ["markdown"],
+ "onlyMainContent": true
+}
+```
+
+This prevents refactoring FROM one outdated pattern TO another outdated pattern.
+
+### 5. Verification Statement
+
+Before refactoring, state:
+```
+"Pre-refactoring check:
+- README/docs read: [list]
+- Dependent files identified: [list files that import this code]
+- Blast radius: [N files affected]
+- Tests exist: [YES/NO — if NO, write tests first]
+- Pattern verified: [YES via research / YES matches codebase / SKIP — trivial refactor]"
+```
+
+---
+
+## Refactoring Principles  [HIGH freedom]
+
+1. **Behavior stays the same** — tests pass before and after
+2. **Small steps** — one change at a time, verify after each
+3. **Test frequently** — run tests after each change
+4. **Commit often** — easy to revert if something breaks
+5. **Research first** — don't replace old patterns with other old patterns
+6. **Scope holds** — a smell outside the named target is a note in the report, not part of this refactor; a bug you find is a follow-up. Tests added here cover the seam being moved or match what the repo already keeps; scratch checks stay out of the repo. Move code in place rather than rewriting whole files.
+
+---
+
+## Code Smells and Fixes  [HIGH freedom]
+
+| Smell | Symptom | Solution |
+|-------|---------|----------|
+| **Long Function** | >20 lines, does multiple things | Extract functions |
+| **Duplicate Code** | Same logic in 2+ places | Extract shared function/hook |
+| **Magic Numbers** | Unexplained literals | Named constants or config |
+| **Deep Nesting** | 3+ levels of if/loops | Early returns, extract functions |
+| **Long Parameter List** | >3 parameters | Object parameter with interface |
+| **Feature Envy** | Function uses another module's data heavily | Move function to that module |
+| **God Object** | One class/component does everything | Split by responsibility |
+| **Primitive Obsession** | Using strings/numbers where a type would be safer | Create domain types |
+| **Shotgun Surgery** | One change requires editing many files | Consolidate related logic |
+| **Dead Code** | Unreachable or unused code | Not this skill — proving it dead is `plan-dead-code`, deleting it is `housekeep-dead-code`. Note it and move on |
+
+---
+
+## Common Refactorings  [HIGH freedom]
+
+### Extract Function
+
+**Before:**
+```typescript
+function processOrder(order: Order) {
+ if (!order.items.length) throw new Error('Empty order');
+ if (!order.customer) throw new Error('No customer');
+ if (order.total < 0) throw new Error('Invalid total');
+
+ const subtotal = order.items.reduce((sum, i) => sum + i.price, 0);
+ const tax = subtotal * 0.1;
+ const total = subtotal + tax;
+
+ db.orders.insert({ ...order, total });
+}
+```
+
+**After:**
+```typescript
+function processOrder(order: Order) {
+ validateOrder(order);
+ const total = calculateTotal(order);
+ saveOrder({ ...order, total });
+}
+```
+
+### Flatten Nested Conditionals
+
+**Before:**
+```typescript
+function getDiscount(user: User, order: Order) {
+ if (user) {
+ if (user.isPremium) {
+ if (order.total > 100) {
+ return 0.2;
+ } else {
+ return 0.1;
+ }
+ }
+ }
+ return 0;
+}
+```
+
+**After:**
+```typescript
+function getDiscount(user: User | null, order: Order) {
+ if (!user) return 0;
+ if (user.isPremium && order.total > 100) return 0.2;
+ if (user.isPremium) return 0.1;
+ return 0;
+}
+```
+
+### Replace Magic Numbers
+
+```typescript
+// Before
+if (password.length < 8) { ... }
+if (retries > 3) { ... }
+const tax = amount * 0.1;
+
+// After
+const MIN_PASSWORD_LENGTH = 8;
+const MAX_RETRIES = 3;
+const TAX_RATE = 0.1;
+```
+
+### Use Object Parameters
+
+```typescript
+// Before — positional args are error-prone
+function createUser(name: string, email: string, age: number, role: string) { ... }
+
+// After — named, self-documenting, extensible
+interface CreateUserParams {
+ name: string;
+ email: string;
+ age: number;
+ role: string;
+}
+function createUser(params: CreateUserParams) { ... }
+```
+
+---
+
+## Refactoring Process  [LOW freedom — run exactly]
+
+```
+1. Verify tests pass → 2. Make one small change → 3. Verify tests pass → 4. Commit → 5. Repeat
+```
+
+### Commit Message Format
+```
+refactor(scope): description of structural change
+
+- What was changed and why
+- No behavior change
+```
+
+---
+
+## Refactoring Checklist  [LOW freedom — do not skip]
+
+### Before Starting
+- [ ] Tests pass (if no tests, write them first)
+- [ ] Understand current behavior
+- [ ] All dependent files identified
+- [ ] Pattern researched (if introducing new pattern)
+- [ ] Specific smell identified
+
+### During Refactoring
+- [ ] One change at a time
+- [ ] Tests run after each change
+- [ ] Working states committed
+
+### After Refactoring
+- [ ] All tests still pass
+- [ ] Code is more readable
+- [ ] No behavior changes
+- [ ] Performance not degraded
+- [ ] All dependent files updated
+- [ ] Types still correct (no new `any` or casts)
+
+---
+
+## When NOT to Refactor  [LOW freedom — do not skip]
+
+- No test coverage (write tests first)
+- Don't understand the code yet (read and learn first)
+- Code is being deleted soon
+- The refactoring has no clear benefit
+- Under deadline pressure (ship first, refactor in a follow-up)

package/skills/workflow-release-prep/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: workflow-release-prep
+description: >
+  Take the local working tree to a merge-ready PR against main: review, split
+  if needed, commit, push, open the PR, drive CI green; never merge. Use when
+  "prepare this for a PR" or "get my working tree merge-ready". Existing PR →
+  workflow-pr.
+license: MIT
+effort: high
+---
+
+# workflow-release-prep — Local working tree → merge-ready PR
+
+**Degree of freedom: MIXED.**
+
+- Review & readiness (Phases 1–2): **HIGH freedom** — judge whether the
+  change is coherent and safe.
+- Git operations (Phases 0, 3–5): **LOW freedom** — commit / push / PR
+  mechanics run exactly, in order. A wrong branch or a force-push is
+  real damage.
+
+Apply-now, end to end. Take everything in the **local working tree** —
+uncommitted + staged + untracked + unpushed commits, reviewed together as
+one release unit — and drive it to a merge-ready PR against main.
+**Do not merge.** This orchestrates existing skills rather than
+re-implementing them: hand deep passes to the specialists, own the
+sequence and the go/no-go.
+
+Scope is the **local working tree only** — not open PRs, not
+merged-unreleased work. One developer's pending change, prepared properly.
+
+## This skill vs neighbors
+
+| Skill | Owns |
+|---|---|
+| **workflow-release-prep** (this) | Whole dirty tree → merge-ready PR; sequence + verdict |
+| `workflow-pr` | Lifecycle of an **already-committed** / existing PR, including merge |
+| `workflow-launch-ready` | Product launch sweep (SEO / PWA / i18n), not git prep |
+| `workflow-quality-gate` | Pre-release *quality* sweep; does not commit or open a PR |
+| `workflow-git-commit` | Conventional commit messages only |
+| `audit-code-review` | Quality / security / maintainability of a named diff |
+| `split-to-prs` (Cursor extra) | Slice one pile into reviewable PRs — wait for approval |
+| `babysit` (Cursor extra) | Keep an **open** PR green (comments / conflicts / CI) |
+| `housekeep-backlog` | What's *not* done across the repo |
+| `docs-adr` | Decisions made along the way |
+
+Pre-release trio: `housekeep-backlog` (what's parked) → this skill
+(what's done, onto a PR) → `docs-adr` (decisions).
+
+## How to reason
+
+1. **Observe** — unstaged + staged + untracked + unpushed as one unit
+2. **Interpret** — one reviewable concern, or several tangled together?
+3. **Classify** — GO / SPLIT / BLOCKED
+4. **Severity** — a secret or broken test blocks; formatting churn does not
+
+## Worked example
+
+> **Observe:** feature + leftover `console.log` + an unrelated lockfile bump.
+> **Interpret:** two concerns; debug residue is a completeness fail.
+> **Classify:** SPLIT the lockfile; remove the log; then GO.
+> **Gate:** do not open a PR around the leftover debug print.
+
+---
+
+## Phase 0 — Snapshot the working tree  [LOW freedom — run exactly]
+
+Establish what's pending before touching anything:
+
+- `git status` and `git branch --show-current` — confirm you are **not**
+  on `main` / `master`. If you are, stop and create a feature branch
+  first. Committing release prep straight to main is the failure this
+  guards.
+- `git diff` (unstaged) + `git diff --staged` — the complete change set,
+  reviewed as one.
+- `git log origin/main..HEAD --oneline` (fall back to `origin/master` if
+  that is the default) — already-committed, unpushed work on this branch
+  is part of the release unit.
+- `git status --porcelain` — untracked files are easy to forget to add.
+
+State the full pending scope: modified, staged, unstaged, untracked, and
+unpushed-committed. That aggregate is what gets reviewed.
+
+---
+
+## Phase 1 — Review the whole change together  [HIGH freedom]
+
+Read **`audit-code-review`** and run it on the **aggregate** diff. Do not
+duplicate its quality / security / maintainability logic.
+
+Then add the release lens a single-diff review misses:
+
+- **Coherence** — one logical unit, or several unrelated ones tangled
+  together? If several → Phase 2 splits them.
+- **Completeness** — half-finished work about to ship? Cross-check the
+  markers `housekeep-backlog` / `plan-stub-checker` hunt: new
+  `TODO` / `FIXME`, `console.log` / debug prints, commented-out code,
+  `.skip`ed tests, stubbed handlers. Release prep is when these must not
+  slip through.
+- **Accidental inclusions** — secrets or keys (→ `plan-secrets-audit` if
+  suspected; **never commit them**), `.env` files, large binaries,
+  editor / OS cruft, debug config, unrelated formatting churn.
+- **Migration / flag safety** — if the diff touches schema or flags, is
+  it backward-compatible for the deploy window? Unsure →
+  `plan-data-integrity` / `workflow-feature-flag`.
+
+---
+
+## Phase 2 — Reason about readiness, then decide split  [HIGH freedom]
+
+Run this chain before proceeding:
+
+1. **Observe** — what does the aggregate contain, across how many concerns?
+2. **Interpret** — one reviewable PR, or unrelated changes a reviewer
+   cannot evaluate together?
+3. **Decide** — single PR, or split? If it spans multiple unrelated
+   concerns or is large enough to be unreviewable, hand to
+   **`split-to-prs`** and prepare each separately. A 2000-line PR mixing
+   a feature, a refactor, and a dependency bump is three PRs.
+4. **Gate** — is anything blocking release (secret, broken test,
+   half-finished feature)? If yes, surface it and **stop before
+   committing** — do not prepare a PR around a known problem.
+
+## Self-critique before committing  [LOW freedom — do not skip]
+
+Challenge the change against this rubric. If any item fails, fix or
+surface it before Phase 3:
+
+- **Complete** — nothing half-implemented, no debug residue, no
+  stubbed-and-forgotten path.
+- **Clean** — no secrets, no accidental files, no unrelated churn
+  padding the diff.
+- **Coherent** — one logical unit per PR (or split decided).
+- **Tested** — the change is covered, or the coverage gap is named
+  (→ `plan-test-coverage`). Existing tests are not broken.
+- **Safe** — migrations backward-compatible; flags default off; no
+  breaking API change to a live consumer without a note.
+
+---
+
+## Phase 3 — Commit  [LOW freedom — run exactly]
+
+Stage deliberately (`git add` the intended files — not blanket
+`git add .` if untracked cruft exists). Hand message-writing to
+**`workflow-git-commit`** for conventional-commit format. One commit per
+logical change; a split PR set gets its own commits per PR. Never bundle
+unrelated changes in one commit.
+
+---
+
+## Phase 4 — Push & open the PR  [LOW freedom — run exactly]
+
+- Push the feature branch (`git push -u origin <branch>`). Never
+  force-push a shared branch.
+- Open the PR against main via **`workflow-pr`**, with a complete
+  description: what changed and why, how it was tested, any migration /
+  flag / rollout notes, and links to the relevant `docs-adr` or `BL-`
+  backlog items if this closes them. A reviewer should not have to
+  reverse-engineer intent.
+- Confirm the repo's aggregator / required checks fire on the PR
+  (`housekeep-gates` / `workflow-quality-gate` if those exist here).
+  This skill does not run those sweeps; it makes sure they are wired
+  to fire.
+
+---
+
+## Phase 5 — Drive to merge-ready  [LOW freedom — hand off]
+
+Hand to **`babysit`** to keep the PR merge-ready: address bot / review
+feedback, resolve straightforward conflicts, fix red CI, loop until
+green and reviewed. **Stop at merge-ready — do not merge.** The human
+(or a separate release step) makes the merge call. This job ends at
+"green, reviewed, and waiting for the button."
+
+---
+
+## Definition of Done
+
+- [ ] Working tree snapshotted; confirmed on a feature branch, not main
+- [ ] Full pending scope (unstaged + staged + untracked + unpushed)
+      reviewed as one unit via `audit-code-review`
+- [ ] Release-lens checks done: coherence, completeness, no debug / stub
+      residue, no accidental inclusions, migration / flag safety
+- [ ] Self-critique rubric passed (complete / clean / coherent / tested /
+      safe); blockers surfaced, not papered over
+- [ ] Split decision made; multi-concern work routed to `split-to-prs`
+- [ ] Committed via `workflow-git-commit` (conventional, one logical
+      unit per commit)
+- [ ] Pushed to a feature branch (no force-push); PR opened via
+      `workflow-pr` with a complete description
+- [ ] Aggregator / required checks confirmed firing on the PR
+- [ ] Driven to merge-ready via `babysit`; **not** merged
+
+## Output format
+
+1. **Pending scope** — files by state; what's included
+2. **Review summary** — `audit-code-review` findings + release-lens
+   findings, severity-ordered
+3. **Readiness verdict** — GO / SPLIT / BLOCKED, with the self-critique
+   rubric result
+4. **Actions taken** — commits made, branch pushed, PR link
+5. **Merge-ready status** — CI state, outstanding review items, what
+   remains before the human merges
+
+Stop at merge-ready. Handoffs: `audit-code-review`, `split-to-prs`,
+`workflow-git-commit`, `workflow-pr`, `babysit`, `plan-secrets-audit`
+(if secrets suspected).

package/skills/workflow-ship-and-observe/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: workflow-ship-and-observe
+description: >
+  Take merged, green code to a verified, monitored production release. Use
+  when "ship it", "deploy to production", "release this", "go live", "roll
+  this out", "promote to prod", or "cut a release" for a running app (npm
+  packages → deploy-npm).
+license: MIT
+---
+
+# workflow-ship-and-observe — Release, Verify, Observe, Roll Back
+
+**Degree of freedom: MIXED.** Rollback-vs-hotfix `[HIGH freedom]`; pin
+target/SHA, prove revision, observe window `[LOW freedom — run exactly]`.
+
+Shipping is not merging. A release is done only when the **intended revision is
+live on the confirmed target, production smoke checks pass, and a defined
+monitoring window elapses without crossing rollback thresholds** — or a
+rollback/hotfix has been executed.
+
+> **Prove the deployed revision, then watch it.** A 200 from a URL is not proof
+> that your code is live, and "it deployed" is not proof that it is healthy.
+
+**Before any browser action, read `protocol-browser-anti-stall`.**
+
+## How to reason
+
+1. **Pin** — SHA, environment, mechanism, rollback, signals
+2. **Ship** — pipeline deploy; backend deps first
+3. **Prove** — live revision equals SHA; smoke on critical flows
+4. **Watch** — window elapsed under thresholds, or roll back
+
+## Worked example
+
+> **Pin:** `a1b2c3d` on Vercel production; rollback = previous promotion; Sentry + 5xx threshold set.
+> **Ship:** migrations applied; `vercel deploy --prod` succeeded.
+> **Prove:** `/version` returns `a1b2c3d`; checkout + login smoke 2xx.
+> **Watch:** 2h window, error rate flat → STABLE. A 5xx spike would have promoted previous and re-smoked.
+
+## Self-critique before reporting
+
+- **Revision proven** — a 200 is not "our SHA is live"
+- **Level honest** — deployed-verified ≠ observed-stable
+- **Threshold acted** — known-bad prod was not "monitored more"
+- **Right owner** — smoke methodology only → `deploy-verify`; npm package → `deploy-npm`; not-yet-green → `workflow-green-repo`
+
+## Phase 0 — Pin the target and the revision  [LOW freedom — run exactly]
+
+Never guess where or what you are shipping. Establish:
+
+1. **Source revision** — the exact commit SHA to release. Confirm it is merged
+   and that the repository is green (route to `workflow-green-repo` /
+   `complete-everything` if not). Record the SHA.
+2. **Target environment** — which environment and provider. Discover from the
+   repo, do not assume: `vercel.json`, `netlify.toml`, `fly.toml`,
+   `Dockerfile`, `render.yaml`, Kubernetes manifests, GitHub Actions deploy
+   workflows, `app.json`/EAS, `supabase/config.toml`, Terraform. Confirm the
+   environment (staging vs production) with the user once and reuse it.
+3. **Deploy mechanism** — CI-on-merge, a manual pipeline trigger, or a CLI
+   command. Identify the exact command/workflow and how to read its status.
+4. **Backend dependencies** — migrations, edge functions, RLS, buckets,
+   secrets, cron. Per `full-stack-ship-discipline`, these must deploy and be
+   verified alongside the frontend. Non-destructive schema required by the
+   approved release ships without re-asking on a confirmed target; destructive
+   data operations always ask first.
+5. **Rollback plan** — the concrete, executable way to revert this target
+   (previous deployment promotion, image/tag rollback, revert-and-redeploy,
+   migration down-path). If no rollback exists, say so before shipping.
+6. **Signals** — where errors and latency are observed (Sentry, provider logs,
+   Supabase logs/advisors, uptime checks) and the thresholds that mean "roll
+   back."
+
+Write `.cursor/ship-state.md`:
+
+```md
+# Ship & Observe: <app> → <environment>
+Revision: <sha>
+Target/provider: <name>
+Deploy: <command/workflow>
+Rollback: <exact procedure>
+Monitor window: <duration> · thresholds: <error rate / latency / crash-free>
+
+## Steps
+- [ ] preflight: repo green + revision confirmed
+- [ ] backend deps deployed + verified
+- [ ] deploy triggered
+- [ ] deployed revision matches <sha>
+- [ ] production smoke: <critical flows>
+- [ ] monitoring window elapsed within thresholds
+- [ ] stable OR rollback/hotfix executed
+
+## Evidence
+- <step>: <command/result>
+```
+The state file is the source of truth across context compaction and across the monitoring window; re-read it before each phase and before any claim.
+
+## Phase 1 — Preflight  [LOW freedom — run exactly]
+
+- Confirm the release SHA is merged and green. Do not ship red or unmerged code.
+- Deploy and verify backend dependencies first, so the frontend does not hit a
+  missing table/function on first request. Verify objects exist as the role the
+  client uses.
+- Confirm the rollback procedure is real and, where possible, dry-run it.
+
+## Phase 2 — Deploy  [LOW freedom — run exactly]
+
+- Trigger the deploy via the identified mechanism. Never hand-edit production
+  state outside the pipeline.
+- Wait for the deploy to reach a terminal state; capture the build/deploy logs.
+  A failed or partial deploy is a stop-and-fix, not a proceed.
+
+## Phase 3 — Verify the revision is live  [LOW freedom — run exactly]
+
+- Confirm the **deployed revision equals the intended SHA** — via the
+  provider's deployment metadata, a `/version`/build-id endpoint, a build stamp,
+  or asset hashes. A reachable URL alone is not proof.
+- Run production smoke checks on the critical flows: real navigation, auth,
+  a primary read and a primary write path. Capture console, network (2xx where
+  expected), and screenshots as evidence. Keep artifacts under `.playwright-mcp/`.
+
+## Phase 4 — Observe the stability window  [LOW freedom — run exactly]
+
+- Watch the defined signals for the agreed window (scale it to release risk).
+- Track error rate/new issues (Sentry), latency and 5xx (provider/Supabase
+  logs), new ERROR advisors, and crash-free rate for mobile.
+- **Crossing a threshold triggers Phase 5.** Not crossing it after the window
+  elapses is the only path to a "stable" claim.
+
+## Phase 5 — Roll back or hotfix (only if a threshold is crossed)  [HIGH freedom]
+
+- If signals breach thresholds: execute the rollback procedure immediately,
+  confirm the prior healthy revision is live, and re-verify smoke checks.
+- If forward-fix is clearly faster and safer than rollback, ship a hotfix
+  through the same pipeline and re-enter Phase 3. Record the decision and why.
+- Never leave production in a known-bad state to "monitor more."
+
+## Phase 6 — Report  [LOW freedom — do not skip]
+
+```md
+## Ship & Observe — report
+Released: <sha> → <environment/provider>
+### Result: STABLE | ROLLED BACK | HOTFIXED | BLOCKED
+### Evidence
+- deploy: <log/status>
+- revision live: <how confirmed> = <sha>
+- smoke: <flows> → <result + artifacts>
+- monitoring: <window> → error rate <x>, latency <y>, crash-free <z>
+### Rollback/hotfix (if any)
+- trigger: <threshold crossed> → action: <what ran> → outcome
+### Follow-ups
+- none | <tracked item>
+```
+
+Completion level is **deployed-verified** after Phase 3 and **observed-stable**
+only after Phase 4 passes. Do not claim stability from a single smoke test.
+
+## Related
+
+- `deploy-verify` — the post-deploy smoke methodology this skill builds on
+- `deploy-npm` — for npm package releases (not app deployments)
+- `full-stack-ship-discipline` — backend must deploy and be verified too
+- `iterate-post-launch` — turn observed production signals into the next fixes
+- `workflow-feedback-to-closure` — route rollback/incident findings into tickets
+- `verification-before-completion` — deployed-verified vs observed-stable levels