dsh-compound-engineering 0.0.0-stage → 0.1.0

package/skills/ce-pov/references/grounding.md

@@ -0,0 +1,47 @@
+# Grounding the POV (Phase 1 machinery)
+
+Read this before dispatching scouts. It defines how the Ground step (SKILL.md Phase 1) runs: which model each scout uses, where scratch files go, what each scout receives, which scouts run at each tier, and how grounded facts are kept apart from unconfirmed ones.
+
+## Model Tiers
+
+Dispatch is tiered by task shape, never hardcoded to a model name:
+
+- **Extraction tier** — the project-grounding scout and the precedent-&-activity scout: search-and-quote work. Use the platform's cheapest capable model when the harness exposes a known override; otherwise inherit.
+- **Generation tier** — the external-evidence researcher: web/docs retrieval and entailment checking. Use the platform's mid-tier model when a known override exists; otherwise inherit.
+- **Ceiling tier** — the final assessment stays with the agent running `ce-pov`, even when another agent delegated the task to it. That agent checks whether the evidence is sufficient, weighs skeptical findings, and produces the required result. Research subagents gather evidence; they do not make this final assessment.
+
+If the user's or project's active instructions or the live prompt name a model for this subagent, use that model instead of the default tier above. They can name it by the subagent's tier, by its prompt-asset name, or for the subagents being dispatched. Without such an instruction, a model configured for this subagent's role takes precedence over the default tier.
+
+**When per-agent models cannot be chosen.** If the platform's subagent mechanism cannot select a model per agent, dispatch every scout on the inherited model and keep their read budgets. Cost control then comes from the read budgets and the tier-sensitive scout count, not from tiering.
+
+When a scout dispatch is rejected, first check whether an agent launched. If the rejection was a bad argument before launch, correct it once. If the platform is out of capacity, leave the work queued. If a launch still fails after the correction, gather that scout's bounded evidence inline and lower the verdict's stated confidence.
+
+Create the scratch dir once, and reuse the echoed path for every scout this run:
+
+```bash
+SCRATCH_ROOT="/tmp/compound-engineering-$(id -u)";
+[ ! -L "$SCRATCH_ROOT" ] && (umask 077; mkdir -p "$SCRATCH_ROOT") 2>/dev/null && [ ! -L "$SCRATCH_ROOT" ] && [ -O "$SCRATCH_ROOT" ] && [ -w "$SCRATCH_ROOT" ] || SCRATCH_ROOT="${TMPDIR:-/tmp}/compound-engineering-$(id -u)";
+if [ -L "$SCRATCH_ROOT" ]; then echo "unsafe scratch root symlink: $SCRATCH_ROOT" >&2; exit 1; fi;
+(umask 077; mkdir -p "$SCRATCH_ROOT") || exit 1;
+if [ -L "$SCRATCH_ROOT" ] || [ ! -O "$SCRATCH_ROOT" ]; then echo "scratch root is not owned by the current user: $SCRATCH_ROOT" >&2; exit 1; fi;
+chmod 700 "$SCRATCH_ROOT" || exit 1;
+SCRATCH_DIR="$SCRATCH_ROOT/ce-pov/$(openssl rand -hex 4)";
+(umask 077; mkdir -p "$SCRATCH_DIR") || exit 1; chmod 700 "$SCRATCH_DIR" || exit 1;
+echo "$SCRATCH_DIR";
+```
+
+**Scoping applies on both paths.** Use the project's active instructions already in context. If the candidate cannot be scoped from the frame and existing context, allow one targeted root or workspace probe. This holds whether this phase dispatches scouts or resolves the facts with bounded inline reads.
+
+**Every scout prompt carries the same context.** A fresh subagent does not inherit this conversation, so fill the persona files' `{subject}` / `{scratch-dir}` placeholders at dispatch. Pass each scout the framed question (subject + intent), the named incumbent and the reversibility tier, and the resolved `<scratch-dir>` path, plus any user-supplied links for the external researcher. A scout seeded with only its generic persona grounds "some external thing" and can produce an empty or unfocused dossier.
+
+A generic subagent is one whose whole brief is the prompt you send it. When the host's subagent tool makes you name an agent, use only a name you have seen the host list, and list its agents before the first dispatch if you have not. Pick the plain one that adds no role of its own, which still counts as a generic subagent. Never pick a specialist, such as a reviewer or worker agent, whose own role prompt, output format, or tool limits would replace or narrow your prompt.
+
+**Which scouts run depends on the tier.** For **Tier 1** (reversible), run a single combined grounding pass: seed one subagent with `references/agents/project-grounding-scout.md` covering the candidate-specific project facts (incumbent, call-sites) at a tight read budget, and one with `references/agents/external-evidence-researcher.md`. Skip the standalone precedent scout; on this tier the project-grounding scout's **prior-decision scan** (`<root>/solutions/`, ADRs, design docs) is the precedent check, so it must run. For **Tier 2/3**, dispatch all three scouts in parallel:
+
+- **project-grounding scout** (extraction tier) — read `references/agents/project-grounding-scout.md` and seed a generic subagent with it. Run the **candidate-specific** slice fresh: the named incumbent for *this* candidate, its call-sites/footprint, incumbent-pain, exact runtime or framework constraints that materially affect compatibility, and the project/candidate/dependency license check. Do not start with generic shape discovery; the project floor (the minimum verified project evidence a verdict needs, defined in `references/method.md`) still requires a freshly verified call-site and current compatibility evidence.
+- **precedent-&-activity scout** (extraction tier) — read `references/agents/precedent-activity-scout.md` and seed a generic subagent with it. Always run its **local-doc precedent pass** (`<root>/solutions/`, ADRs, design docs — file reads, no tools needed); only its tracker/PR portion depends on a reachable tracker and is skipped, with a note, when those interfaces aren't reachable. Do **not** skip the whole scout for missing tracker access; that would drop the only path that finds a prior local adopt/reject decision.
+- **external-evidence researcher** (generation tier) — read `references/agents/external-evidence-researcher.md` and seed a generic subagent with it; it runs only when web tools are reachable. **Scale its brief to the tier so Tier 3's deeper workup is real, not nominal.** At **Tier 3**, seed it with a deeper brief: a wider source net, a larger read budget, and *mandatory* two-source corroboration on every claim the verdict depends on (at Tier 3 a single-source claim cannot anchor the verdict). **Tier 2** uses the persona's standard budget and its prefer-two-sources default.
+
+**Skip work only when nothing can reach it.** Skip a scout, or a portion of one, only when it has **no reachable interface at all**. The project-grounding scout and the precedent scout's local-doc pass are file reads and always run; the tracker/PR reads and the external researcher need tools and are skipped when those tools are absent. Let a scout that loses a tool mid-run report "unavailable" itself. Never block on a missing interface. Record it and let it lower the verdict's stated confidence, or fail the external floor in Phase 2 (Verify Grounding) when the external leg is entirely absent.
+
+**Sort every fact by where it came from** using the returned dossiers and your own bounded inline-read observations, and keep the groups separate for Phase 2 (Verify Grounding): *observed-project-facts* and *verified-external-facts* count as grounding; *conversation-claims* and *unconfirmed-assumptions* from a warm invocation do not count until a scout or a bounded inline read of the authoritative source corroborates them. Read dossiers from their paths on demand; do not pull their bulk into this context.

package/skills/ce-pov/references/intake.md

@@ -0,0 +1,61 @@
+# Establish the Frame Before Grounding
+
+Settle the question before gathering decision-specific evidence. SKILL.md defines how to interact with the user and how to return to the caller.
+
+If the request belongs to another skill, finish intake by routing it there. Send understanding questions to `ce-explain` with the subject and intended use. For other work outside this skill’s scope, return the route identified in `references/boundaries.md`. Do not issue a verdict or continue to tiering, selection, or evidence gathering. If the named capability is unavailable, report that limitation to the caller.
+
+Every settled POV applies the reversibility tier and selection escape hatch below. A clear frame can proceed directly to those checks; an ambiguous one follows the skill body's interaction rule before decision-specific research.
+
+## Output mode and warm invocations
+
+By default this skill writes no document. Deliver the POV to its consumer. A requested write-up uses Phase 4 (Deliver and return); do not read rendering instructions for an ordinary answer.
+
+A **warm** invocation is a mid-session second opinion, with the question sitting in the conversation or absent. On one, read `references/invocation.md`, and take only the *question and claims-to-verify* from the conversation, never grounding.
+
+## Why this check exists
+
+The same subject supports very different verdicts. A link to a new sign-in method could mean "should we **adopt** it?", "should we **migrate** to it, and how costly?", "how does it **compare** to what we have?", or "I just have a **question** about it." Guessing "migrate" sends all three scouts after migration cost and answers a question the user never asked. The frame determines what the scouts look for, so settle it first.
+
+## Step 1 — Orient on what was provided (cheap, pre-grounding)
+
+- **A bare link** → fetch it lightly (one fetch) to learn what the thing *is*; name it. If you cannot fetch it (no web tool, paywalled), return the missing subject information under the skill body's interaction rule.
+- **A bare topic or name** → recognize it from your own knowledge; a single search only if you genuinely can't place it.
+- **A document path** → read its headings to learn its purpose and shape; do not review it for findings yet.
+- **An approach set** → identify the options already on the table; do not invent additional options during orientation.
+- **A paste or provided context** → read it.
+
+This is orientation, not grounding — keep it to one read/fetch. The project and external grounding (the scouts) come *after* the frame is set.
+
+## Step 2 — Determine the POV intent
+
+The subject is usually recoverable; the **intent** is the ambiguous part. Classify it:
+
+- **Adopt** — use this new capability (net-new, or no incumbent)?
+- **Migrate / replace** — switch *from an incumbent* to this?
+- **Compare** — how does it stack up vs. what we have or the alternatives (no switch implied)?
+- **Exposure** — is this (a CVE, deprecation, or ecosystem change) *our problem*?
+- **Document-take** — what is the holistic take on this document: its strengths, risks, and bottom line, rather than a findings review?
+- **Approach-set** — which of the supplied approaches fits this project, and why, or are the options honestly viable either way?
+- **Explainer** — the requested result is understanding. Route to `ce-explain`, preserving the question and intended use.
+
+## Step 3 — Resolve the frame
+
+Resolve shorthand from the active conversation when one referent fits. A clear subject and intent need no confirmation. When competing readings would materially change the judgment, investigate what can be established and return **Blocked — missing context** with the remaining information needed, under the skill body's interaction rule. Do not start research or a panel on an invented question.
+
+Uncertainty that does not affect the decision need not stop a recommendation supported by evidence. You may state a supported assumption if it does not invent a product commitment or choose an unresolved user preference. Still obtain any required approval before sending information to an unexpected external recipient or acting outside existing permission.
+
+An understanding request belongs to `ce-explain`; no reversibility tier, selection workup, or verdict is required on that route.
+
+## Tier, sizing, and the selection hatch
+
+These two decide **every** invocation, however clear the frame already was.
+
+**Apply the selection escape hatch** (the rule that stops this skill from judging a field it would have to invent). If the input is a *selection* over a field ("what should we use for auth?"), it belongs here only when the realistic field is bounded (roughly five or fewer real candidates) and the criteria are knowable. If judging the field would require inventing options, or the criteria are unclear, **stop**. Return a Hold that explains what is missing and identifies the skill that can resolve it. Use `ce-bakeoff` to develop competing solutions to a defined brief, `ce-ideate` to explore an open opportunity field, or `ce-brainstorm` to bring out goals and criteria. Bake-off selects and synthesizes its own result. A subsequent POV is an optional second opinion. Continuing through that route follows the follow-up authority check in `references/followup.md`.
+
+**Classify the reversibility tier — three levels.** Infer it from project signals:
+
+- **Tier 1 — two-way door:** a dependency, lint rule, or config; trivially reversible.
+- **Tier 2 — one-way but bounded:** a data store, an internal API/contract, or a migration whose blast radius stays inside this codebase.
+- **Tier 3 — one-way and high-stakes:** a security, legal, or privacy surface; a public API/contract; or an irreversible data migration.
+
+The tier determines how much investigation and verification to do, not the answer’s format. Tier 1 uses a combined grounding pass. Tier 2 adds all three scouts and an alternatives pass. Tier 3 adds deep external research and precedent search. Explain the stakes when they affect the recommendation. Do not run a Tier-3 workup on a trivially reversible `npm i`, or hand a security-surface decision the moderate Tier-2 treatment.

package/skills/ce-pov/references/invocation.md

@@ -0,0 +1,47 @@
+# Invocation Contexts
+
+Read this for a **warm** invocation (SKILL.md Phase 0, Frame and Classify). The method is one method; warm changes *where the question comes from* and *how much ceremony is warranted*, not the workflow.
+
+## Cold vs warm
+
+- **Cold** — the user opens with an explicit external question at session start. Run the full method at the warranted tier.
+- **Warm** — `ce-pov` is dropped into a live session ("weigh in", "give me your POV on this") and the question lives in the surrounding conversation, or is absent.
+
+## What warm takes from the conversation: the question only
+
+The conversation supplies the **question** and the **claims-to-verify** — *nothing else*. It is **not** grounding. The biggest failure here is consensus laundering: twenty turns of you and the agent mutually assuming "we must migrate off X" quietly become "grounding," and the result is a confident verdict that ratifies chat fiction.
+
+So every input is labeled by where it came from, and only verified buckets satisfy the grounding check (see `references/method.md`):
+
+| Bucket | Counts as grounding? |
+|---|---|
+| Observed project facts (from a scout dossier or a host bounded read of the authoritative source) | Yes |
+| Verified external facts (from a scout dossier or a host bounded read of the authoritative source) | Yes |
+| Conversation claims | No — frame and hypotheses until a scout or a bounded inline read of the authoritative source corroborates |
+| Unconfirmed assumptions | No — shown to the user to confirm or deny |
+
+If the conversation says "we have 40 call-sites on X," the project-grounding scout — or the host's own bounded read, when the sites are already located — must confirm that against the codebase before it counts. **Warm adds no evidentiary weight.** It brings out the question and hypotheses; the independent grounding is still done by scouts or bounded reads of the source, never by the conversation itself. The same invalidation rule applies, with no warm exemption.
+
+## Establishing the question (frame gate)
+
+The frame gate is the check that the question is settled before research starts. A warm invocation with **no explicit question**, or a materially ambiguous one, goes through it in `references/intake.md`: resolve the decision from context and evidence, and return essential missing context to the caller. Rendering a confident POV on the wrong question is the warm-mode failure that check prevents. **Skip the check** when the user named the question ("ce-pov: should we use X?"); a mandatory confirm on every warm run is the bureaucratic ritual the skill avoids.
+
+Short references are intentional: "on the approach," "these options," or "the three options presented" resolve from the active conversation when one referent fits. Return missing context to the caller when competing meanings would materially change the POV and the conversation cannot distinguish them. `oracle` requests immediate panel convergence; explicit peer names in the same invocation select those exact participants and override oracle discovery and its automatic cap. `Cursor` means the Cursor harness's configured default/Auto model; `Composer` means a Composer model reached through Cursor, not an alias for Cursor.
+
+A warm panel request (a "summons" in `references/cross-model-panel.md`) that names an already-formed position to oracle — the host's prior POV or the user's own view — is the prior-opinion subject case (see `references/cross-model-panel.md` Section 1), not a revision prompt: the position ships as the subject and peers form their own verdict. A follow-up panel request after pushback re-enters the panel with a fresh round before any position change is emitted.
+
+## Be more adversarial than cold — operationalized
+
+The conversation's momentum pulls toward agreement, and a second opinion that rubber-stamps is worthless. "More adversarial" is not an attitude; it is two concrete rules:
+
+1. Run an **explicit disconfirming-evidence pass** on each conversation claim the verdict depends on: try to refute it from the grounded evidence (scout dossiers or bounded inline reads) before accepting it.
+2. **Never upgrade a grade on conversation momentum alone.** If the only thing pushing toward Adopt is that the room already wants it, that is not grounding, and the grade does not move.
+
+## Guest output contract
+
+Warm is a guest, not a host:
+
+- Consult a peer only when the warm invocation explicitly requests one; never make a proactive panel offer mid-session.
+- Output a **requested POV only** — no reframing of the host session, no taking over the brainstorm.
+- The POV is the last thing this skill writes. It ends this skill, not the turn. The host session's next step follows it.
+- **Skip the capture offer** unless the user asks — a mid-session interjection should not push a durable-record decision.

package/skills/ce-pov/references/method.md

@@ -0,0 +1,68 @@
+# Method and Point-of-View Contract
+
+Read this before reasoning about the POV (SKILL.md Phase 2, Verify Grounding). It defines the Verify and POV steps, the two cross-cutting properties, the grounding gate (the evidence check every POV must pass), and the output contract for each subject shape.
+
+## The four steps
+
+1. **Frame** (Phase 0, Frame and Classify) — the question, incumbent, horizon, and success criteria are settled, and a question with no bounded set of candidates has already been returned as a Hold under Phase 0's rule for open fields.
+2. **Precedent** (Phase 1, Ground) — the scout that looks for prior stances and recent activity has reported whether a prior stance exists. Precedent informs the order but does not have to come first: a CVE's urgency can lead, but you still read the precedent before grading.
+3. **Verify** (Phase 2, Verify Grounding) — apply the evidence check below to the evidence gathered so far (the scouts' reports and what you read directly from the authoritative source within the allowed budget).
+4. **Point of view** (Phase 3, Point of View) — deliver the content the contract for the active subject shape below requires.
+
+## Two cross-cutting properties (not phases)
+
+- **Skeptic stance.** At every step, seek disconfirming evidence and name the real alternatives — including "keep the incumbent" and "do nothing." "No", "Reject", and "Not-our-problem" are first-class outcomes, not failures to complete. Do not let the framing (or, in warm mode, where the question grew out of the ongoing conversation, that conversation's momentum) pull the grade upward. When the POV goes against something the user backed with evidence, answer that evidence directly rather than leaving it out.
+- **Reversibility-tiered effort.** Scale evidence gathering and verification with the cost of being wrong. The tier assigned at intake sets how deep research goes; presentation follows the consumer's needs. Preserve material alternatives and the conditions that would change a consequential judgment.
+
+## The grounding gate
+
+The project floor (the minimum verified project evidence a POV needs) always applies. The external floor (at least one verified outside source) applies in full to an external-adoption question. For a document or approach set, it applies only to external claims that materially support the POV's bottom line; when the bottom line depends on no external claim, no external source is required. A conversation claim (warm mode) never satisfies either floor until a scout or a bounded inline read of the authoritative source corroborated it — it sits in the *conversation hypotheses* bucket, never the *verified facts* bucket.
+
+A call to another function establishes that the call occurs, not how that function behaves. Verify guarantees against the implementation or tests that establish them. When those sources are unavailable, keep the guarantee unknown in the explanation or recommendation. Label inferred purpose where you state it; a later caveat does not make an unsupported claim safe to use.
+
+A recommended change is also a claim about the project. Before recommending one, find what already does that job (a skill, script, setting, or recorded decision) and name it, or say that nothing does. This applies to every recommendation, including ones added after the main verdict.
+
+### External-adoption questions: the two-floor Invalid-Verdict gate
+
+The verdict must clear **two absolute floors**. They are independent: strong external evidence never compensates for thin project evidence, and vice versa. This is a pass/fail checklist, **not** a comparison of how much evidence each side has.
+
+- **Project floor** — PASS requires the verdict to rest on a concrete, *verified* project fact relevant to the decision, in one of these forms: a **named incumbent plus at least one concrete touchpoint** (a `file:line`, dependency, issue, PR, or doc passage from the dossiers or a bounded inline read) for a replace/migrate; the **verified absence of an incumbent plus a concrete integration/fit point** (where it would slot in, the conventions it must match) for a net-new adoption; or a **prior decision** on the question. FAIL means the project was not actually inspected. Return **"Hold — insufficient project grounding"** with a numbered list of exactly what to inspect to make the floor passable. Never return Adopt or Reject on a failed project floor, regardless of how strong the external evidence is.
+- **External floor** — PASS requires at least one verified external source whose text supports the claim it backs. FAIL (for example, no research tools were reachable) means return **"Hold — external evidence unavailable"**, not a graded verdict at lowered confidence.
+
+A conversation claim (warm mode) never satisfies a floor until a scout or a bounded inline read of the authoritative source corroborated it — it sits in the *conversation hypotheses* bucket, never the *verified facts* bucket.
+
+### Documents and approach sets: explicit blocker returns
+
+Apply the same project-floor proof standard to a document or approach set, using a concrete verified project fact relevant to the take or choice. If it fails, return **"Blocked — insufficient project grounding"** with a numbered list of exactly what to inspect to make the floor passable. If the take or choice depends on an external claim that no verified external source supports, return **"Blocked — external evidence unavailable"** with a numbered list of exactly what evidence would make the floor passable. Do not disguise either failure as a confident bottom line.
+
+## External-adoption verdict contract
+
+Every verdict preserves the grade vocabulary so decisions remain comparable and discoverable in precedent searches.
+
+**Grade** — exactly one of:
+
+- **Adopt** — proven fit for us; use it.
+- **Trial** — promising; use on a low-risk slice first; the next step is a scoped spike.
+- **Hold** — a complete, valid decision to *wait* (promising but unstable, migration cost exceeds current pain, category moving too fast). "Hold — insufficient project grounding" and "Hold — external evidence unavailable" are the two gate-failure subtypes.
+- **Reject** — judged not worth it for us.
+- **Not-our-problem** — for an exposure question (CVE / deprecation) that does not reach us — avoids forcing an adopt/reject.
+
+When a test that takes a few minutes and changes no project files would settle a **Trial**, or a **Hold** that is not a gate failure, name that test as the next step, specifically enough to run. For a Trial, that test is the scoped spike.
+
+Preserve the grade and its meaning, incumbent or integration point, verified project and external evidence, material conditions, and what would change a consequential verdict. Keep unverified conversation claims distinguishable from evidence. These are content requirements, not mandatory headings or a fixed layout. A recommended next action is useful only when the result calls for one; it is not permission to execute it.
+
+## Document-take contract
+
+A document POV judges its overall direction rather than inventorying findings. Explain the bottom line and the strengths, risks, and verified project facts that determine it. Verify the external claims the take depends on, and keep unverified conversation claims distinguishable. Applying revisions belongs to the workflow responsible for the document, under the follow-up authority check in `references/followup.md`.
+
+## Approach-set position contract
+
+An approach-set POV judges developed options supplied by the user, conversation, or calling skill. When comparison requires developing concrete solutions beyond their current form, route to `ce-bakeoff`; discovering an open field belongs to `ce-ideate`, and establishing goals or criteria belongs to `ce-brainstorm`. Preserve the reasons, material tradeoffs, evidence, and conditions behind the position.
+
+Choose when evidence provides a real basis. When the options are genuinely viable either way, say **"Either is viable"** and explain the tradeoffs. Never manufacture certainty with a scorecard or a mechanical count of advantages. Proceeding with an approach is a separate action governed by the follow-up authority check in `references/followup.md`.
+
+## Delivery
+
+Write the chat block through the `ce-noslop` skill.
+
+SKILL.md defines how to adapt the result to its consumer. Keep enough cited evidence to assess the judgment, name what remains uncertain, and make any option or requirement identifiers understandable. Do not reproduce research transcripts. Requested artifacts use `references/report.md`; ordinary answers need no artifact or continuation menu.

package/skills/ce-pov/references/pov-schema.json

@@ -0,0 +1,56 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "Cross-model point of view",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["voice", "position", "reasoning", "evidence", "external_check", "mode", "movement", "final"],
+  "properties": {
+    "voice": {
+      "type": "string",
+      "minLength": 1,
+      "description": "Short identity for the peer voice; the worker namespaces it to the provider."
+    },
+    "position": {
+      "type": "string",
+      "minLength": 1,
+      "description": "The adoption grade, document or approach bottom line, skeptic verdict, or blocked state."
+    },
+    "reasoning": {
+      "type": "string",
+      "minLength": 1,
+      "description": "Concise reasoning for the position, including the reason when blocked."
+    },
+    "evidence": {
+      "type": "array",
+      "items": {
+        "type": "string",
+        "minLength": 1,
+        "description": "A succinct claim with a URL, file:line, or named document section attribution."
+      }
+    },
+    "external_check": {
+      "type": "string",
+      "enum": ["ran", "unavailable"]
+    },
+    "mode": {
+      "type": "string",
+      "enum": ["independent", "skeptic"]
+    },
+    "movement": {
+      "type": "string",
+      "enum": ["initial", "moved", "held"],
+      "description": "Initial position, or whether the voice moved or held during reconciliation."
+    },
+    "final": {
+      "type": "boolean",
+      "description": "true when position is your settled answer (a settled Blocked verdict counts); false when you have not finished inspecting and position is a placeholder."
+    },
+    "cross_model_route": { "type": "string" },
+    "cross_model_target": { "type": "string" },
+    "cross_model_harness": { "type": "string" },
+    "serving_family": { "type": "string" },
+    "model_requested": { "type": "string" },
+    "model_actual": { "type": "string" },
+    "independence_verified": { "type": "boolean" }
+  }
+}

package/skills/ce-pov/references/report.md

@@ -0,0 +1,7 @@
+# Requested Write-Up
+
+Expand the judgment for its intended readers and destination. Preserve the active subject's evidence and conditions from `references/method.md`: an adoption grade, a document's overall take, or a position among supplied approaches. Do not turn a document take or approach comparison into an adoption report.
+
+Use the requested format or the destination's supported format. When none is specified, choose what makes the result usable. Cite project sources and any external sources the judgment depends on. Distinguish inference from evidence and retain the conditions that could change the judgment. Do not paste raw dossiers.
+
+Write a standalone file to private scratch and deliver its path. Resolve the CE artifact root before writing to a requested project location. When another workflow is responsible for the surrounding document, return the content for it to incorporate. A request for a write-up does not authorize publishing it. When publication is requested, use the destination’s available tools and follow its authorization requirements. If publication cannot complete, retain the local result and report the limitation.