mishkan-harness 0.2.0 → 0.2.4

package/payload/mishkan/skills/graphify-query-craft/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: graphify-query-craft
+description: |
+  Use `graphify query "<question>"` to traverse the project's code-structure
+  graph for structural questions ("who calls X", "what depends on Y", "where
+  is the entry point") at ~1.8k tokens per query — 88.1× cheaper than
+  lifting the full source tree into context (verified on MISHKAN harness,
+  POC 2026-06-07). Use BEFORE grep / Read on source files whenever the
+  question is about code STRUCTURE rather than code SEMANTICS.
+  For every code-touching agent across the dev teams (per D-009 amended scope, 2026-06-07): Yasad backend (Hizkiah, Nathan, Zadok, Shallum, Uriah), Panim frontend (Salma, Oholiab, Asaph, Jahaziel), Chosheb UI (Hiram), Mishmar code-security (Ira, Joab, Hushai), Migdal infra-code (Palal, Meshullam, Meremoth, Hanun), Sefer documentation (Joah, Shevna, Jehonathan).
+---
+
+# Graphify query craft
+
+## When to call
+
+The crisp test from D-008's epistemological frontier:
+
+> **Structure question → Graphify.**
+> **Semantic question → Cognee work.**
+
+Examples of **structure** questions you should answer with a `graphify
+query` BEFORE reading any file:
+
+- "Who calls `process_payment`?"
+- "What depends on the `User` model?"
+- "Where is the main entry point?"
+- "What is the call graph for the auth flow?"
+- "What are the god nodes in this codebase?"
+- "What connects the data layer to the API?"
+- "Show me everything that imports `pandas`."
+
+Examples of **semantic** questions that go to Cognee work, not Graphify:
+
+- "Why was X deprecated?"  → ADR in Cognee work
+- "What did we decide about Y last sprint?" → decision in Cognee work
+- "How does the team handle Z?" → runbook in Cognee work
+
+If you can't tell which side of the line you're on, prefer Graphify
+first — its answer is cheaper and structurally precise. Cognee work is
+the right second hop when the Graphify answer is structurally correct
+but the engineer needs the WHY.
+
+## How to call
+
+The graphify CLI lives outside Claude Code (installed via
+`uv tool install "graphifyy>=0.8.33"` — pin matters: 0.8.33 fixed the
+test-file-orphan bug; earlier 0.8.x silently dropped test edges).
+It writes graphs into `<project>/graphify-out/` and the queries
+traverse `graphify-out/graph.json`.
+
+```bash
+# First, make sure the graph is current — fast on warm cache:
+graphify update .
+
+# Then ask the question:
+graphify query "who calls process_payment"
+```
+
+### Pick the right traversal
+
+- **`query`** (default BFS, ~2k tokens) — for "what surrounds this
+  concept" questions. Fans out from the seed.
+- **`query --dfs`** — for **tracing a flow** when you already know the
+  entry node. Returns the call chain rather than the surrounding cluster.
+  Example: `graphify query "process_payment" --dfs` walks the call chain
+  from `process_payment` outward, single-thread.
+- **`affected <node> --depth N --relations calls,imports`** — reverse
+  BFS. Pre-commit blast-radius check. Use BEFORE editing a function
+  whose downstream impact you don't fully know.
+- **`path A B`** — directional shortest path. Add `--calls "[A]-->[B]"`
+  to constrain to a specific edge family. Answers "does X ever reach Y?"
+  without grep.
+- **`explain <node>`** — node + neighbors + community context. Use when
+  you have a known symbol and want a quick map of its surroundings —
+  cheaper than `query`.
+
+### Always pass `--context` explicitly
+
+Graphify's heuristic edge-type detection is brittle on mixed-language
+repos (well-documented community gotcha). When you know the question is
+structural-calls, say so:
+
+```bash
+graphify query "who handles payment events" --context call --context import
+graphify affected "User" --relations imports
+```
+
+This consistently outperforms heuristic-detection on the MISHKAN harness
+and avoids the "why didn't it find that obvious caller" trap.
+
+### Budget is rarely the dial you want
+
+Default `--budget 2000` stays near 2k tokens even on 500k-word corpora.
+Raising past ~8k almost always means **wrong seed** rather than budget
+shortage. If the answer feels thin, re-seed (better question) before
+re-budgeting.
+
+The output is plain text that lists the graph path + the relevant
+`file:line` citations. Cite them in your answer — per D-008
+"citation discipline":
+
+> When an agent answers from Graphify, it cites the graph node id and
+> the source `file:line`. No "according to the graph" without an id.
+
+## Cite, then optionally Read
+
+A Graphify answer typically narrows the relevant set from "the whole
+repo" (158k tokens) to "5-10 file:line citations" (~1.8k tokens). When
+the engineer needs prose context for ONE of those citations, THEN you
+Read that single file. The savings come from not Read-ing the other 200
+files just to find the relevant ones.
+
+Worked example, full flow:
+
+```
+1. Engineer: "Refactor process_payment to use the new TransactionContext."
+
+2. You (Hizkiah / Salma / Nathan / Zadok / Oholiab):
+   $ graphify query "who calls process_payment"
+   → 7 file:line citations returned, ~1.8k tokens spent.
+
+3. You: Read the 7 cited files (selective, not bulk).
+
+4. You: Edit each call site to thread TransactionContext.
+```
+
+Without Graphify, step 2 becomes "grep recursively + Read every match"
+which on a 158k-token corpus is ~80k+ tokens minimum and frequently
+misses indirect dispatch.
+
+## What graphify CAN'T do
+
+- It does not understand call dispatch via dynamic strings (`getattr`,
+  `eval`, `dict-of-callables`). Those edges are invisible.
+- It does not capture runtime configuration (env vars, feature flags).
+  Those are not in the AST.
+- It does not understand cross-language boundaries (a Python call to a
+  Node script via subprocess). Each language's AST is its own island.
+
+When the question requires those, fall back to grep + Read with a
+narrowed file set, or escalate to Cognee work for the documented
+intent.
+
+## Fail-open
+
+If `graphify-out/graph.json` is missing or stale, run `graphify update
+.` first (sub-second on warm cache). If the project doesn't use
+Graphify at all (no `graphify-out/` dir), proceed with grep + Read as
+normal — no graph means no Graphify query path, that's fine.
+
+## Reference
+
+- D-008 — three-store knowledge surface (Graphify · Cognee work · Cognee
+  curated). The epistemological frontier between the three is the source
+  of "which question goes where". See `docs/design/MISHKAN_decisions.md`.
+- D-009 — graph-first PreToolUse advisory hook for the five code-writing
+  specialists. The hook will, in Phase 2, surface a one-line reminder if
+  you do a structural Read without consulting Graphify first.
+- POC report — `docs/research/graphify-token-saving-poc.md` (88.1×
+  average reduction, verified on MISHKAN harness 2026-06-07).
+- Upstream Graphify — https://github.com/safishamsi/graphify.

package/payload/mishkan/skills/mishkan-init/SKILL.md

@@ -46,6 +46,21 @@ to Y4NN before the first doc is written — the plan is the scope contract for i
    the team rules from `~/.claude/mishkan/rules/*` → `.claude/rules/*` for
    path-scoped loading, and `~/.claude/mishkan/templates/mcp.json` → `./.mcp.json`
    so agents can reach the Cognee knowledge-graph MCP.
+10. **Automated — Graphify code graph** (the third store of the knowledge stack,
+    per D-008): if `graphify` is on PATH (`uv tool install graphifyy` provides
+    it), run an initial scan so the project has a structure graph from Sprint
+    S0 onwards. Otherwise skip with a one-line note — the agent fleet still
+    works; the graph populates the first time Hizkiah / Salma / Nathan / Zadok /
+    Oholiab runs `graphify update .` mid-sprint.
+    ```bash
+    if command -v graphify >/dev/null 2>&1; then
+      graphify update . || echo "mishkan-init: graphify scan failed, skipping (project will scan on first structural query)"
+    fi
+    ```
+    The output `graphify-out/` is gitignored by convention — re-derivable, no
+    need to commit. The MISHKAN observability daemon's `graphify_tail` source
+    will start emitting `graphify_scan` / `graphify_query` events for the
+    Knowledge tab as soon as the graph exists.
 
 ## Outputs
 

package/payload/mishkan/skills/skill-discovery/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: skill-discovery
+description: Universal skill-discovery layer for the main session. Routes a task to the most relevant installed skills across MISHKAN, the user's ~/.claude/skills, plugin-bundled skills, and project-local skills. Returns three buckets — must_load, should_consider, adjacent — capped at 13 entries total. Advisory only; the model decides what to actually load. Use when a task arrives and you suspect a relevant skill exists but you cannot remember its name, when the surface of installed skills has grown past what fits in working memory, or when /skills is invoked explicitly.
+---
+
+# skill-discovery — main-session router
+
+> The harness has dozens of installed skills across four roots. This layer
+> answers one question for the main session: *given this task, which skills
+> should I be aware of right now?* It does **not** load skills; it surfaces
+> them. The loading decision remains with the model.
+
+---
+
+## When to invoke
+
+- A new task arrives and the relevant skill name is not immediately obvious.
+- The user types `/skills` (the slash command runs this skill directly).
+- A workflow declares `relevant_skill_categories` and asks for skill candidates
+  before its first stage runs.
+- You catch yourself about to do work you suspect a skill already encodes —
+  ask the router before improvising.
+
+**Do not invoke** when the right skill is already named in the request, or
+when the work is trivial enough that no skill applies (a one-line edit, a
+direct git command, a clear file read).
+
+---
+
+## How to invoke
+
+Run the router script with the task description on `--task` (or piped on
+stdin). The router reads the universal index at
+`~/.claude/mishkan/skill-discovery/index.json` and emits a 3-bucket JSON.
+
+```
+python3 ~/.claude/mishkan/scripts/skill-discovery-router.py \
+    --task "<one-paragraph task summary>" \
+    [--workflow <workflow-name>] \
+    [--relevant-categories cat1,cat2]
+```
+
+If the index is missing or stale, run the indexer first (it is also wired to
+session-boot via `--stat-only`):
+
+```
+python3 ~/.claude/mishkan/scripts/skill-discovery-indexer.py --rebuild
+```
+
+---
+
+## Interpreting the three buckets
+
+The router returns three buckets, hard-capped at **13 entries total**:
+
+| Bucket | Cap | Semantics | What you do |
+|---|---|---|---|
+| `must_load` | ≤ 3 | Score ≥ threshold_high; strong trigger match | Load these into context; treat them as the directly-relevant skills for the task. |
+| `should_consider` | ≤ 5 | Mid-band score; partial match | Skim the description; load if the work clearly intersects. Prefer keeping these *as references* over auto-loading them. |
+| `adjacent` | ≤ 5 | Low score but same category | Awareness only; mention if relevant; do not load by default. |
+
+**Bias rule.** When the count is tight (e.g. must_load is full but a
+should_consider entry looks more relevant than a borderline must_load entry),
+prefer enriching should_consider rather than padding must_load. The cost of
+loading a wrong skill is higher than the cost of skipping a marginal one.
+
+---
+
+## Trust asymmetry — load only what you trust for the work
+
+Each entry carries an `origin` field: `mishkan`, `user`, `plugin`, `project`.
+
+- `mishkan` entries are harness-authored and trusted by default.
+- `user` / `plugin` / `project` entries are third-party and carry a `trust`
+  warning in the router output.
+
+**Rule.** Never auto-load a non-MISHKAN skill for a stateful operation
+(anything in y4nn-standards §5: `git push`, SSH to production, `docker exec`
+on prod, `sudo`, schema migration, log forensics). Surface them; ask Y4NN
+before loading.
+
+For generative work (boilerplate, doc draft, refactor sketch), non-MISHKAN
+skills can be loaded once you've read the description and judged the fit.
+
+---
+
+## Name collisions
+
+The indexer enforces precedence order at index time:
+**mishkan → user → plugin → project**. Collisions are recorded in
+`index.json.meta.collisions` (a shadowed skill is not silently dropped — it
+is logged). If you suspect a collision is shadowing the skill you want, run
+`/mishkan-skills-reindex` and inspect `meta.collisions`.
+
+---
+
+## Failure mode — fail-open
+
+If the router returns empty buckets, the request is recorded in
+`~/.claude/mishkan/skill-discovery/misses.jsonl` for later tuning. Continue
+the task without the discovery layer — the absence of a router result is not
+a blocker.
+
+If the index is missing or unreadable, the router returns
+`stale_rebuild_needed: true` and `warnings: ["index_missing_or_unreadable"]`.
+Run `/mishkan-skills-reindex` and retry.
+
+---
+
+## Phase 1 scope (canary)
+
+This skill is wired in two places only in Phase 1:
+
+1. The `/skills` slash command — invokes the router on the current task.
+2. The `mishkan-init` workflow — calls the router in an early phase as an
+   advisory hint to Bezalel before doc generation.
+
+Other workflows route through their own craft skills as before. Phase 2 will
+broaden integration once the canary has produced enough misses-log signal
+to tune thresholds.

package/payload/mishkan/templates/case-node.schema.json

@@ -3,6 +3,7 @@
   "$id": "mishkan://templates/case-node.schema.json",
   "title": "MISHKAN Case Node",
   "description": "Written to Cognee when an agent solves a problem using a curated resource (design §8).",
+  "$comment": "SPEC-ONLY artifact. No runtime validator enforces this schema today — it is the canonical shape referenced from MISHKAN_harness_design.md and MISHKAN_ontology.md. To enforce at write time, plumb it through scripts/validate-research-log.sh or a Cognee write hook.",
   "type": "object",
   "additionalProperties": false,
   "required": ["type", "team", "agent", "problem_class", "resource_applied", "resolution", "outcome", "sprint", "task"],

package/payload/mishkan/templates/observability-log.schema.json

@@ -3,6 +3,7 @@
   "$id": "mishkan://templates/observability-log.schema.json",
   "title": "MISHKAN Observability Log Entry",
   "description": "One entry per agent tool call, emitted by the PostToolUse hook (design §10).",
+  "$comment": "SPEC-ONLY artifact. The PostToolUse hook produces lines matching this shape but no runtime validator enforces it — the producer's discipline is the contract. To enforce, add a check in post-tool-observe.sh or a periodic conform pass.",
   "type": "object",
   "additionalProperties": false,
   "required": ["agent", "team", "sprint", "session", "tool_calls", "outcome", "timestamp"],

package/payload/mishkan/workflows/README.md

@@ -1,8 +1,9 @@
 # MISHKAN workflows
 
-Seven dynamic-workflow scripts that codify the orchestrations where
-parallel scale + repeatability justify a script. Each maps to one or
-more of the nine canonical workflow patterns from
+Eighteen dynamic-workflow scripts — ten org-level + eight team-level —
+that codify the orchestrations where parallel scale + repeatability
+justify a script. Each maps to one or more of the nine canonical workflow
+patterns from
 [Anthropic's reference](https://code.claude.com/docs/en/workflows) and the
 [community patterns catalogue](https://github.com/ray-amjad/claude-code-workflow-creator/blob/main/references/patterns.md).
 
@@ -20,25 +21,85 @@ These run from the **main session only** (subagents cannot invoke
 | [`mishkan-architecture-panel.js`](mishkan-architecture-panel.js) | judge panel + impact-fanout + synthesis | Architecture decisions with a wide answer space; 3 Nathan runs from cost/scale/simplicity priors; Zadok+Phinehas+Shallum score; Bezalel synthesises | High-leverage architecture decisions |
 | [`mishkan-release-readiness.js`](mishkan-release-readiness.js) | barrier `parallel()` + structured pass/fail + nested workflow | Pre-deploy gate: tests + security + dependency + SLO + pipeline shape, all at once → single go/no-go | Before every staging-to-prod deploy |
 | [`mishkan-init.js`](mishkan-init.js) | pipeline with overlap (PRD → SRS → CONTRACT+ARCH in parallel → THREAT+C4 in parallel → settle) | Cut project init from hours to minutes without violating the sequence rule | Once per project at `/mishkan-init` |
+| [`mishkan-blast-radius.js`](mishkan-blast-radius.js) | Graphify discovery + 3-lens orthogonal verify + synthesis | "What does this change actually touch?" Refactor blast-radius with three load-bearing lenses (caller-side / data-contract / runtime-behavior) so false positives drop before scheduling | Before editing a function whose downstream impact is uncertain; gated by `/plan` |
+| [`mishkan-knowledge-gap-discovery.js`](mishkan-knowledge-gap-discovery.js) | parallel probe + **loop-until-dry** + research fan-out | Probe Cognee work for expected concepts; the only candidate that legitimately needs loop-until-X — confirm gaps via paraphrase retries before dispatching research | Sprint close (optional barrier step) or after `/sefer-pull` |
+| [`mishkan-standards-rollout.js`](mishkan-standards-rollout.js) | pipeline (translate → verify) + barrier + judge panel (Bezalel + scope-conditional reviewers) | When a new rule lands in `y4nn-standards.md`, it propagates per-team with translation, drift verification, and CTO ratification — closes the silent failure mode of rules drift | When a new standard ships; BEFORE the rule is considered live across the fleet |
 
 ## The patterns each script uses
 
 | Pattern | Used by |
 |---|---|
-| Fan-out → synthesize | `codebase-audit`, `release-readiness`, `architecture-panel` |
-| Pipeline (overlapping) | `deep-research`, `migration-wave`, `init` |
-| Barrier `parallel()` | `sprint-close`, `release-readiness`, `architecture-panel` (Vote stage) |
+| Fan-out → synthesize | `codebase-audit`, `release-readiness`, `architecture-panel`, `blast-radius` |
+| Pipeline (overlapping) | `deep-research`, `migration-wave`, `init`, `standards-rollout` |
+| Barrier `parallel()` | `sprint-close`, `release-readiness`, `architecture-panel` (Vote stage), `knowledge-gap-discovery`, `standards-rollout` |
 | Adversarial verification (3-vote refute) | `deep-research`, `codebase-audit` |
-| Judge panel | `architecture-panel`, `migration-wave` (2-reviewer accept) |
+| Orthogonal 3-lens verify (caller / data / runtime) | `blast-radius` |
+| Judge panel | `architecture-panel`, `migration-wave` (2-reviewer accept), `standards-rollout` (Bezalel + scope-conditional) |
 | Nested workflow | `release-readiness` → `codebase-audit` |
-| Loop-until-X | — (mechanism inside scripts when needed; no top-level loop workflows yet) |
+| Loop-until-X | `knowledge-gap-discovery` (paraphrase-retries to confirm gaps before research) |
+
+## Team-level catalogue
+
+Eight team-level workflows codified per ADR D-010 (cap 4/team, PM+CTO
+co-owned). Invoked through the Team Lead's craft skill.
+
+| Script | Pattern combo | Real problem it solves | Team |
+|---|---|---|---|
+| [`chosheb-feature-ship.js`](chosheb-feature-ship.js) | barrier + synthesis | Design → handoff package complete (DS fit + a11y + assets + QA) | Chosheb |
+| [`panim-ds-rollout.js`](panim-ds-rollout.js) | pipeline + worktree + judge panel | Design token change propagated to all consumers with a11y + regression review | Panim |
+| [`yasad-data-migration-wave.js`](yasad-data-migration-wave.js) | pipeline + 4-lens judge panel | Wave of DB migrations, per-table reviewed (contracts/perf/security/tests) | Yasad |
+| [`yasad-schema-evolution.js`](yasad-schema-evolution.js) | pipeline + per-phase judge panel | Phased schema change with zero-downtime invariants + per-phase rollback | Yasad |
+| [`mishmar-security-gate.js`](mishmar-security-gate.js) | barrier + 3-vote adversarial refute | Security gate on sensitive surface (auth/payment/PII), 3 orthogonal lenses | Mishmar |
+| [`migdal-infra-change.js`](migdal-infra-change.js) | barrier + 5-lens panel | Infra change validated by design/systems/devops/observability/health lenses | Migdal |
+| [`migdal-dr-drill.js`](migdal-dr-drill.js) | pipeline + per-step judge panel | DR drill — enumerate, simulate, verify, RTO/RPO measurement, gap report | Migdal |
+| [`sefer-release-notes.js`](sefer-release-notes.js) | pipeline + per-category fan-out + style synthesis | Release notes assembled from git log per category with style-guide application | Sefer |
+
+Spare slots (Chosheb 3, Panim 3, Yasad 2, Mishmar 3, Migdal 2, Sefer 3)
+are deliberately open; candidates compete for them at PM+CTO review.
+
+## Portfolio governance — D-010
+
+The portfolio is **PM + CTO co-owned** with hard caps and an anti-pattern
+canon (ADR D-010, 2026-06-07). Nehemiah owns scope, delivery, recurrence
+justification; Bezalel owns orchestration shape, schema contracts, quality
+bar. New workflows land through joint review — not ad hoc.
+
+**Hard caps.** 10 org-level (full) + 4 per team (varies). To add, retire.
+**Soft retirement.** Workflows that fire < 2× in 3 sprints surface at
+`/sprint-close` for PM+CTO retirement vote; default is `workflows/proposed/`.
+
+The June 2026 portfolio review produced the org-level additions
+(`blast-radius`, `knowledge-gap-discovery`, `standards-rollout`), the
+org-level removal (`multi-perspective-review` was theatre vs the existing
+`architecture-panel`), the eight team-level workflows above, and the
+anti-patterns below.
+
+### Anti-patterns to avoid (D-010)
+
+1. **Skill-in-workflow-clothing.** Linear sequence, no parallelism, no
+   termination predicate, no panel — that's a skill, not a workflow.
+2. **Workflow calling workflow without a contract.** Nested workflows
+   are valid (cf. `release-readiness` → `codebase-audit`) only when the
+   inner workflow's output schema is consumed structurally. Free-form
+   nesting hides token cost and breaks retry semantics.
+3. **Judge panels with non-orthogonal reviewers.** If two reviewers in
+   a panel share 70%+ of their evaluation criteria, the panel is
+   theatre. Each lens must be load-bearing and distinct (`blast-radius`
+   enforces this with caller-side / data-contract / runtime-behavior).
+4. **Workflow-as-status-page.** Orchestration that fans out to gather
+   state without synthesis is a dashboard query, not a workflow. If the
+   synthesis stage is missing or trivial, the work belongs in
+   observability, not in `Workflow()`.
 
 ## Cost discipline
 
 Workflows are expensive. The community baseline is **3–6 workflows per
-production team**. Seven is the working ceiling — adding more
-typically means the new use case is better served by Task delegation
-or a skill.
+production team**. The MISHKAN hard cap is **10 org-level + 4 per team**
+(current count: 10 org + 8 team across 6 teams = 18 total). Adding more
+typically means either (a) the new use case is better served by Task
+delegation or a skill, or (b) an existing workflow should be retired —
+soft-retirement happens after a workflow fires < 2× across 3 sprints,
+under PM+CTO review.
 
 Cost expectations per run (subagent-tokens, rough orders of
 magnitude):
@@ -52,6 +113,9 @@ magnitude):
 | `mishkan-architecture-panel` | medium | 3 proposals × 3 reviewers + synthesis |
 | `mishkan-release-readiness` | low-medium | 7–8 parallel checks; nested audit if enabled |
 | `mishkan-init` | medium | 6 artefacts pipelined |
+| `mishkan-blast-radius` | medium | `sites × 3 lenses` + discovery + synthesis; short-circuits on empty graph |
+| `mishkan-knowledge-gap-discovery` | medium-high | probe × N concepts + loop-until-dry rephrasings + research fan-out per gap |
+| `mishkan-standards-rollout` | low-medium | 6 translations + 6 verifications + 1-3 ratifiers (scope-conditional) |
 
 Run on a small slice first (one directory; one phase) before
 committing to a full wave.
@@ -76,8 +140,9 @@ Don't, unless:
 3. The repeatability is real (same orchestration each time, just different inputs).
 
 Otherwise: Task fan-out from the main session is the right answer.
-The seven workflows above were picked precisely because each clears
-all three bars.
+The 10 org-level + 8 team-level workflows above were picked precisely
+because each clears all three bars; the portfolio is capped at 10 + 4
+per team per ADR D-010.
 
 ## Constraints (reminders)
 

package/payload/mishkan/workflows/chosheb-feature-ship.js

@@ -0,0 +1,75 @@
+// chosheb-feature-ship — design → handoff package complete to Panim.
+//
+// A Figma / design intent + feature context goes in; a complete handoff
+// package comes out: design system fit, a11y/SEO audit, asset exports,
+// QA visual matrix. Replaces the back-and-forth ping-pong that currently
+// burns 2-3 days per feature.
+//
+// Pattern: barrier `parallel()` per dimension + synthesis.
+// Per ADR D-010 anti-pattern check:
+//   - skill-in-workflow-clothing: no — 4 dimensions in parallel, panel.
+//   - workflow-calling-workflow-without-contract: no — no nesting.
+//   - non-orthogonal panel: no — DS-fit / a11y / assets / QA are distinct
+//     evaluation domains.
+//   - workflow-as-status-page: no — synthesis stage produces handoff doc.
+
+export const meta = {
+  name: "chosheb-feature-ship",
+  description: "Design → complete handoff package for Panim (DS fit + a11y + assets + QA).",
+  whenToUse: "When Chosheb has a converged design and Huram needs to start implementation.",
+  phases: [{ title: "Audit" }, { title: "Package" }],
+};
+
+const design = args?.design_ref;
+const feature = args?.feature_context;
+if (!design) throw new Error("args.design_ref is required (Figma URL / asset path)");
+if (!feature) throw new Error("args.feature_context is required (1-paragraph feature description)");
+
+const AUDIT_SCHEMA = {
+  type: "object",
+  required: ["ready", "blockers"],
+  properties: {
+    ready: { type: "boolean" },
+    blockers: { type: "array", items: { type: "string" } },
+    deliverables: { type: "array", items: { type: "string" } },
+    notes: { type: "string" },
+  },
+};
+
+phase("Audit");
+const LENSES = [
+  { key: "ds-fit",   agent: "aholiab",  prompt: "Design system fit: does this design reuse existing tokens / components / patterns? List net-new additions to the DS." },
+  { key: "a11y",     agent: "asaph",    prompt: "Accessibility + SEO audit: contrast ratios, keyboard flow, ARIA needs, semantic structure, meta requirements." },
+  { key: "assets",   agent: "obed",     prompt: "Asset preparation: list required exports (svg/png/webp per breakpoint), sizes, naming, optimisation notes." },
+  { key: "qa",       agent: "jahaziel", prompt: "Visual QA matrix: states (default/hover/active/disabled/error), breakpoints, edge cases, browser/device coverage." },
+];
+
+const audits = await parallel(LENSES.map(L => () =>
+  agent(
+    `Feature: ${feature}\nDesign: ${design}\nYour lens: ${L.prompt}\nReturn the schema.`,
+    { schema: AUDIT_SCHEMA, label: `audit:${L.key}`, agentType: L.agent, phase: "Audit" },
+  ).then(a => ({ ...L, ...a }))
+));
+
+const valid = audits.filter(Boolean);
+const allBlockers = valid.flatMap(a => a.blockers ?? []);
+const allReady = valid.every(a => a.ready);
+
+phase("Package");
+const handoff = await agent(
+  `Chosheb → Panim handoff package. Feature: ${feature}. Audits: ${JSON.stringify(valid.map(a => ({lens: a.key, ready: a.ready, deliverables: a.deliverables, notes: a.notes})))}. ` +
+  `Produce a structured handoff document: design summary, DS additions list, a11y checklist, asset manifest, QA matrix, open questions. Markdown.`,
+  { label: "package-handoff", agentType: "aholiab", phase: "Package" },
+);
+
+return {
+  feature_context: feature,
+  design_ref: design,
+  audits: valid,
+  ready_to_ship: allReady,
+  blockers: allBlockers,
+  handoff_document: handoff,
+  summary: allReady
+    ? `Handoff package ready. ${valid.length}/4 lenses passed. Hand to Huram (Panim).`
+    : `Handoff BLOCKED. ${allBlockers.length} blockers across ${valid.length} lenses. Resolve before handoff.`,
+};

package/payload/mishkan/workflows/migdal-dr-drill.js

@@ -0,0 +1,94 @@
+// migdal-dr-drill — disaster recovery drill orchestration.
+//
+// A DR scenario (region loss, DB corruption, secret leak, control-plane
+// outage) is specified; the workflow orchestrates the drill: enumerate
+// recovery steps, simulate per step, verify each via independent observer,
+// measure RTO/RPO against target. Synthesises a drill report with gaps.
+//
+// Pattern: pipeline (enumerate → simulate → verify) + barrier + judge panel.
+// ADR D-010 check:
+//   - parallelism: simulation step × independent observer per step.
+//   - panel orthogonality: Palal (systems-level recovery) + Hanun (operational
+//     observability during drill) + Rehum (health/safety post-recovery).
+//   - synthesis: RTO/RPO measurement + gap list.
+
+export const meta = {
+  name: "migdal-dr-drill",
+  description: "Disaster recovery drill — enumerate steps, simulate, verify, measure RTO/RPO, report gaps.",
+  whenToUse: "Quarterly DR exercise, or after any infra change that affects recovery topology.",
+  phases: [{ title: "Plan" }, { title: "Simulate" }, { title: "Report" }],
+};
+
+const scenario = args?.scenario;
+const rtoTarget = args?.rto_target_minutes ?? 30;
+const rpoTarget = args?.rpo_target_minutes ?? 5;
+const project = args?.project ?? ".";
+if (!scenario) throw new Error("args.scenario is required (e.g. 'primary-region-loss' | 'db-corruption' | 'secret-leak')");
+
+const PLAN_SCHEMA = {
+  type: "object", required: ["steps"],
+  properties: { steps: { type: "array", items: { type: "object", required: ["order", "action", "expected_outcome"], properties: { order:{type:"integer"}, action:{type:"string"}, expected_outcome:{type:"string"}, depends_on:{type:"array", items:{type:"integer"}} } } } },
+};
+const VERIFY_SCHEMA = {
+  type: "object", required: ["verified", "rationale"],
+  properties: { verified:{type:"boolean"}, rationale:{type:"string"}, gap:{type:"string"}, time_estimate_minutes:{type:"number"} },
+};
+
+phase("Plan");
+const plan = await agent(
+  `DR scenario: ${scenario}. Project: ${project}. RTO target: ${rtoTarget}min, RPO target: ${rpoTarget}min. Enumerate the recovery steps in order with dependencies. Return the schema.`,
+  { schema: PLAN_SCHEMA, label: "plan-recovery", agentType: "palal" },
+);
+
+const steps = plan?.steps ?? [];
+log(`DR plan: ${steps.length} recovery steps.`);
+
+phase("Simulate");
+const OBSERVERS = [
+  { key: "systems", agent: "palal",  prompt: "Systems lens: does this step actually recover the targeted system? Hidden dependencies?" },
+  { key: "ops",     agent: "hanun",  prompt: "Operations lens: are the runbooks ready, secrets accessible, on-call awake, monitoring live during this step?" },
+  { key: "health",  agent: "rehum",  prompt: "Health lens: post-step health checks, data-integrity probes, success criteria. Is the system actually healthy after?" },
+];
+
+const simulated = await parallel(steps.map(S => () =>
+  parallel(OBSERVERS.map(O => () =>
+    agent(
+      `DR scenario: ${scenario}. Step ${S.order}: ${S.action} (expected: ${S.expected_outcome}). Your lens: ${O.prompt} Default verified=false if uncertain.`,
+      { schema: VERIFY_SCHEMA, label: `simulate:${O.key}:step${S.order}`, agentType: O.agent, phase: "Simulate" },
+    )
+  )).then(verdicts => {
+    const valid = verdicts.filter(Boolean);
+    const verifiedCount = valid.filter(v => v.verified).length;
+    const times = valid.map(v => v.time_estimate_minutes ?? 0).filter(t => t > 0);
+    const meanTime = times.length ? times.reduce((a,b)=>a+b, 0) / times.length : 0;
+    return { step: S, verdicts: valid, verified_count: verifiedCount, all_verified: verifiedCount === OBSERVERS.length, gaps: valid.map(v => v.gap).filter(Boolean), time_minutes: meanTime };
+  })
+));
+
+phase("Report");
+const totalTime = simulated.reduce((a, s) => a + (s.time_minutes ?? 0), 0);
+const allGaps = simulated.flatMap(s => s.gaps);
+const failedSteps = simulated.filter(s => !s.all_verified);
+
+const rtoMet = totalTime <= rtoTarget;
+const passes = failedSteps.length === 0;
+
+const report = await agent(
+  `DR drill report. Scenario: ${scenario}. ${steps.length} steps, ${failedSteps.length} failed verification. Estimated RTO: ${totalTime.toFixed(1)}min vs target ${rtoTarget}min. Gaps: ${JSON.stringify(allGaps)}. Produce a markdown report: executive summary, per-step status, gap remediation list.`,
+  { label: "produce-report", agentType: "rehum", phase: "Report" },
+);
+
+return {
+  scenario,
+  rto_target_minutes: rtoTarget,
+  rto_estimate_minutes: totalTime,
+  rto_met: rtoMet,
+  steps_total: steps.length,
+  steps_passed: simulated.filter(s => s.all_verified).length,
+  gaps: allGaps,
+  report,
+  decision: passes && rtoMet ? "ready" : "not-ready",
+  summary: passes && rtoMet
+    ? `DR drill PASS. ${steps.length}/${steps.length} steps verified. RTO ${totalTime.toFixed(1)}min ≤ ${rtoTarget}min target.`
+    : `DR drill FAIL. ${failedSteps.length} unverified steps${rtoMet ? "" : `, RTO ${totalTime.toFixed(1)}min > ${rtoTarget}min target`}. ${allGaps.length} gaps to address.`,
+};