@hassangameryt/freeflow 0.3.0 → 0.4.0

package/skills/review-work/references/reviewer-prompt.md

@@ -1,97 +1,134 @@
-# Reviewer Prompt
+# Independent Work Reviewer Contract
 
-Use this when preparing an outgoing reviewer prompt or subagent review context.
+Use this when preparing an independent review of implementation or integrated work.
 
-The reviewer should get the work product and source truth, not your session memory.
+The reviewer did not produce the work. Give them the work product, source truth, and evidence needed to judge it directly. Do not provide only the author's summary, reasoning, or claimed result.
 
-## Include
+## Required Context
 
-- What was implemented or changed.
-- The source authority: spec, plan, issue, ADR, policy, tests, or user-confirmed requirement.
-- Files or diff range to inspect. If no git range exists, list concrete files.
-- Claimed verification and what still needs independent checking.
-- Risk lenses relevant to the work.
-- Required output shape and severity labels.
-- Clear instruction not to edit files unless the review task explicitly includes fixes.
-- For review pass 2 or 3: prior findings, accepted/rejected/question/needs-evidence adjudication, owner clarifications, changed files, and narrowed remaining risk.
+Provide:
 
-Do not forward only a previous-agent summary. Summaries are useful context, not authority.
+- the work and future action covered by the review;
+- accepted outcome, requirements, and non-goals;
+- relevant specs, plans, tests, policies, ADRs, and established behavior;
+- the implementation, changed files, or diff range;
+- verification evidence and known gaps;
+- only the review lenses material to this boundary;
+- review number and, for a follow-up, prior items, adjudication, corrections, and new evidence.
 
-For second and later review iterations, include prior findings, parent adjudication, owner clarifications, changed files, and the remaining risk. Do not rerun the same broad prompt after the situation narrows.
+When state transitions or proof integrity matter, also provide the invariant or state owner, affecting paths, observing mechanism, forbidden mutations, prior-state requirements, adversarial disproof, mutation footprint, and fidelity limits.
 
-## Risk Lenses
+## Reviewer Prompt
 
-Pick the lenses that fit the work:
+```md
+# Independent Work Review
 
-- Source-truth alignment: implementation matches spec, plan, docs, tests, and established behavior.
-- Regression risk: unrelated behavior changed or broad refactor from narrow work.
-- Security/privacy: auth, secrets, permissions, sensitive data, logging, data exposure.
-- Billing/product: pricing, downgrade/upgrade, access, entitlements, user-visible policy.
-- Public API: route, method, payload, response status/body, compatibility, error semantics.
-- Data safety: migrations, deletion, idempotency, rollback, duplicate processing.
-- Test gaps: claims rely on manual checks, stale notes, or missing executable coverage.
-- Reviewability: diff scope, generated files, hidden dependencies, unexplained deviations.
+Review work you did not produce. Inspect the supplied work, source truth, and evidence directly. Report review items without editing. The review ends with this report; do not fix items, dispatch a follow-up, or keep reviewing merely to obtain Pass.
 
-For strict-workflow or high-risk work, call out owner-owned decisions and stop conditions directly.
+A pass is valid. Do not invent items, broaden scope, or treat possible improvement as unfinished work.
 
-## Output Shape
+## Boundary
 
-Ask the reviewer to lead with findings, ordered by severity:
+[Work and future action this review covers.]
 
-```md
-## Findings
+## Accepted Outcome And Non-Goals
 
-### Blocking
-- [file:line] Title
-  - What is wrong:
-  - Why it matters:
-  - Minimal fix direction:
+- Outcome: [required result]
+- Requirements: [accepted requirements]
+- Non-goals: [intentional exclusions]
 
-### Non-blocking
-- ...
+## Source Truth
 
-### Questions
-- ...
+- [specs, plans, tests, policies, ADRs, and established behavior]
 
-## Assessment
+## Work Product
 
-Ready to proceed: Yes | No | With fixes
-Reasoning: ...
-```
+- Reviewed state: [commit, tree, diff, or other identity]
+- Work: [diff range, changed files, implementation, or integrated result]
 
-If review passes, the reviewer should say that clearly and name any residual test gaps or assumptions.
+## Verification Evidence
 
-If review does not pass, the reviewer should classify findings and stop. Do not tell the parent agent to apply all findings and send it back for another broad review.
+- Checks and results: [commands, observations, and results]
+- Known gaps: [gaps or none]
+- When relevant: [state owner, affecting paths, observer, forbidden mutations, prior-state requirements, adversarial disproof, mutation footprint, fidelity limits]
 
-Do not ask reviewers to invent issues. A clean pass is valid.
+## Review Scope
 
-If this is review pass 3, ask for remaining accepted blocking risk only. Do not recommend a fourth broad review loop.
+- Review number: [1 | 2 | 3]
+- Material lenses: [alignment and correctness | regression and integration | failure and risk | evidence | design and minimality | maintainability]
 
-## Minimal Template
+For Review 2 or 3:
+- Prior items and adjudication: [Accepted | Rejected | Open]
+- Clarifications: [settled decisions or none]
+- Corrections and new evidence: [changes and verification]
+- Remaining risk: [narrow unresolved scope]
 
-```md
-# Reviewer Prompt
+## Check
 
-Review the completed work. Do not edit files.
+Apply only the selected lenses:
 
-## Work Summary
+- The work satisfies accepted behavior without invention or omission.
+- Affected callers, states, and components remain correct together.
+- Relevant failure paths and material risks are handled safely.
+- Verification supports the claims and exercised the required boundary.
+- Complexity and coordination are justified by requirements or observed failures.
+- The work remains understandable and changeable without hidden policy or fragile coupling.
 
-[What changed, from the implementer summary or observed files.]
+Do not search for unrelated issues. Report an out-of-scope issue only when it materially affects whether this boundary may be crossed.
 
-## Source Truth
+A possible edge case is not an Issue without accepted behavior, observed reachability, or material risk. Use Question when expected behavior is unclear, Needs evidence when reachability or consequence is unsupported, and Improvement for useful resilience not required by the boundary.
 
-- [spec/plan/policy/test paths]
+For Review 2 or 3, inspect only accepted corrections, affected interactions, new evidence, and remaining risk. Do not reopen Rejected items without contradictory evidence. For every new Blocking Issue, state whether it repeats, extends, invalidates, or exposes another consequence of a prior correction; is independent; or cannot yet be related from the evidence. Report a related pattern rather than proposing another patch. Review 3 is final for this cycle; do not recommend Review 4.
 
-## Files Or Range
+## Classify Review Items
 
-- [changed files or git range]
+- **Blocking Issue:** supported defect or risk that must be resolved before crossing this boundary.
+- **Non-blocking Issue:** real issue that can be deferred safely for this boundary.
+- **Question:** material intent, requirement, or owner decision is unclear.
+- **Needs evidence:** a plausible concern cannot be established from available evidence.
+- **Improvement:** useful enhancement not required for this boundary. It does not affect judgment or authorize implementation.
 
-## Check
+A Blocking Issue must include its exact location, violated requirement or source truth, evidence, concrete boundary consequence, and smallest safe correction or owning activity to re-enter.
 
-- [risk lenses and concrete requirements]
-- [if pass 2 or 3: prior findings, adjudication, owner clarifications, changed files, and narrowed remaining risk]
+## Determine The Judgment
+
+1. **Blocking:** one or more Blocking Issues exist.
+2. **Inconclusive:** no Blocking Issue exists, but a material Question or Needs evidence item prevents judgment.
+3. **Non-blocking:** only Non-blocking Issues remain.
+4. **Pass:** no Issues or material Unresolved items remain. Improvements may still be reported.
 
 ## Output
 
-Lead with findings by severity. Include file:line, violated requirement, risk, and minimal fix direction. If there are no findings, say so and list residual risk/test gaps.
+Review type: independent
+Review number: [1 | 2 | 3]
+Boundary: [reviewed work and future action]
+Reviewed state: [state identity]
+Judgment: Pass | Non-blocking | Inconclusive | Blocking
+Reasoning: [concise evidence-backed judgment]
+Relationship to prior items (Review 2 or 3 only): [related consequence | independent defect | unclear, with evidence]
+
+### Review Items
+
+#### Issues — Blocking
+- [location, issue, violated source, evidence, consequence, smallest safe correction]
+
+#### Issues — Non-blocking
+- [location, issue, evidence, why it can be deferred]
+
+#### Unresolved — Questions
+- [question, effect on judgment, required answer]
+
+#### Unresolved — Needs evidence
+- [concern, missing evidence, evidence needed]
+
+#### Improvements
+- [improvement, benefit, supporting evidence]
+
+Evidence gaps: [unproved claims or none]
 ```
+
+## Calibration
+
+Use a high evidence bar, not a high item count. Lead with the few items that can change the boundary judgment. Prior review, urgency, implementation effort, or author confidence does not establish correctness.
+
+The review is evidence for adjudication, not authority over source truth, owner decisions, corrections, or another independent dispatch. Pass, Non-blocking, Inconclusive, and Blocking are all valid exits.

package/skills/review-work/references/security-risk-lens.md

@@ -0,0 +1,67 @@
+# Security Risk Lens
+
+Read this when work changes trust boundaries, authentication, authorization, permissions, untrusted input, secrets, sensitive data, dependencies, external integrations, execution, or failure behavior with security consequences.
+
+This lens helps frame review. It does not replace repo security policy, threat modeling, specialist review, or stack-specific hardening guidance.
+
+## Establish Authority
+
+Identify:
+
+- assets and data requiring protection;
+- actors, roles, tenants, and privilege levels;
+- trust boundaries and external systems;
+- accepted security/privacy policy and threat model;
+- compatibility and failure behavior that security controls must preserve.
+
+Security-sensitive product behavior remains user-owned. Do not invent access, retention, logging, or fail-open/closed policy during review.
+
+## Trace The Paths
+
+Review the affected path from boundary to effect:
+
+- authentication: who or what is this actor;
+- authorization: may this actor perform this operation on this resource;
+- input: validation, canonicalization, size, encoding, and injection surfaces;
+- output: escaping, disclosure, error detail, and side channels;
+- data: collection, transport, storage, isolation, retention, deletion, and audit;
+- secrets: source, scope, rotation, exposure, and logging;
+- execution: shell, file, URL, template, deserialization, plugin, or code-loading boundaries;
+- dependencies: provenance, permissions, known risk, update impact, and transitive behavior;
+- failure: partial state, retries, lockout, rate limits, rollback, and fail-open/closed behavior.
+
+Look for confused-deputy and cross-tenant paths, not only malformed input.
+
+## Evidence
+
+Prefer evidence at the real boundary:
+
+- tests proving allowed and denied roles/resources;
+- negative input and injection cases;
+- dependency or configuration inspection tied to the shipped artifact;
+- logs or traces demonstrating no secret/sensitive leakage;
+- failure-path tests for partial authorization, retry, and recovery;
+- specialist analysis for cryptography, sandboxing, identity protocols, or high-impact threats.
+
+A generic scanner pass cannot prove authorization logic or policy correctness. A unit test cannot prove deployed headers, identity configuration, or infrastructure permissions.
+
+Do not copy secrets, credentials, unrestricted personal data, or sensitive payloads into review context. Use the smallest sanitized evidence that supports the review item.
+
+## Review Item Calibration
+
+Treat supported exploitable behavior, policy violation, unintended privilege or data exposure, unsafe failure semantics, secret leakage, or a missing required control as an Issue.
+
+Classify the Issue against the accepted security policy and reviewed boundary:
+
+- **Blocking:** crossing the boundary would remain unsafe, non-compliant, or contrary to a required control.
+- **Non-blocking:** the security issue is real but can be deferred safely without violating the accepted boundary.
+
+Use **Question** when security behavior or accepted risk remains undecided. Use **Needs evidence** when a control may exist but the available test or environment cannot establish it.
+
+Treat materially useful defense-in-depth beyond the accepted boundary as an Improvement. Do not turn theoretical hardening, preference, or hypothetical completeness into an Issue.
+
+Do not omit an observed security issue merely because the selected lenses were narrower. Name the asset, path, precondition, consequence, evidence, and source requirement.
+
+## Route
+
+When security evidence changes the path, use [Workflow](../../workflow/SKILL.md) to choose what follows. Use [Diagnose Failure](../../diagnose-failure/SKILL.md) for unknown exploitability or root cause, [Decision Gate](../../decision-gate/SKILL.md) for missing policy or accepted-risk decisions, [Design For Depth](../../design-for-depth/SKILL.md) when trust decisions spread across callers, and [Launch Work](../../launch-work/SKILL.md) when the concern affects production rollout.

package/skills/setup-freeflow/SKILL.md

@@ -1,106 +1,98 @@
 ---
 name: setup-freeflow
-description: Use when setting up, installing, enabling, initializing, or configuring Freeflow in a repo, choosing Codex/Claude/multi-agent activation, creating `.freeflow/config.json`, or changing the repo default mode during setup.
+description: Use when activating Freeflow in a repository, repairing its repository or personal configuration, or checking whether the current host is delivering Freeflow context.
 ---
 
 # Setup Freeflow
 
-Use `references/activation-contract.md` before rendering activation text, config, or host setup.
+Create or repair the smallest valid layered setup. Keep repository activation, personal overrides, and host runtime delivery as separate facts.
 
-Use `references/host-setup.md` when the request mentions Codex, Claude, both hosts, team setup, solo setup, strict defaults, hooks, CLI, or setup profiles.
+- `.freeflow/config.json` is the required shared repository activation config.
+- `.freeflow/local.json` is an optional per-checkout personal override. It cannot activate Freeflow by itself.
+- Runtime delivery depends on the current host's installed and trusted adapter.
 
-Use `references/output-router-setup.md` when setup reaches the optional evidence-routing decision point or asks for output-router/observed-routing/script-transform repo config, generated-path hints, native safety-net routing, vault settings, or output thresholds.
+Answer setup questions and delivery checks read-only. An explicit action request authorizes the smallest selected setup change under the state rules below. When repository config is missing, first activation authorizes minimal shared config; it does not authorize personal overrides, optional capabilities, replacement of invalid config, or edits to repo-owned host instructions.
 
-## Stop Before Editing
+Read [the activation contract](references/activation-contract.md) before changing setup state. Read [host setup](references/host-setup.md) when runtime delivery, lifecycle, or host trust matters. Read [Output Router setup](references/output-router-setup.md) only when the user explicitly requests it during setup or repair; later tuning belongs to [Output Router](../output-router/SKILL.md).
 
-Do not create config, add activation blocks, imports, or rule files until setup has a clear host target and no unresolved repo-rule conflict.
+## Establish Mutation Authority
 
-Hard stops:
-- both `AGENTS.md` and `CLAUDE.md` exist, and the user did not explicitly choose a host or ask for multi-agent setup
-- existing repo instructions conflict with asking before user-owned decisions
-- existing repo instructions conflict with verification before completion claims
-- Claude setup would add `.claude/rules/freeflow-core.md` but the user has not clearly chosen Claude or multi-agent setup
+Classify the current state before editing:
 
-For a hard stop, make no file changes. Name the blocker and ask one direct question.
+- **Unconfigured:** repository config is missing or invalid, so no Freeflow mode is effective. An explicit setup request may create minimal config when it is missing. Replacing or reinterpreting invalid config still requires the specific authority described below.
+- **Configured but ineffective:** valid repository activation exists, but Freeflow is disabled, Skills are dormant, or invalid local config blocks runtime. No mode is effective. An explicit request governs the selected enablement, configuration, or repair; any dormant resolved mode does not.
+- **Effective:** Freeflow Skills report an effective mode. Obey it. Conversation remains read-only; Workflow or Strict Workflow allows agent-performed mutation only for the separately requested setup or repair.
 
-## Inspect
+User-operated host settings are direct user actions, not agent-performed config edits. Prefer them when available and do not claim their state changed until the host reports it.
 
-Inspect `.freeflow/config.json`, `AGENTS.md`, `CLAUDE.md`, `.claude/rules/freeflow-core.md`, `.codex/rules/`, existing `## Freeflow` blocks, and conflicting repo instructions.
+## Inspect The Layers
 
-Existing repo instructions are source truth. If a rule conflicts with Freeflow's core behavior, name the conflict and ask whether to install Freeflow as advisory, revise the rule, or skip setup. Advisory install is a user decision, not the default.
+Before editing:
 
-## Target
+1. inspect `.freeflow/config.json` and `.freeflow/local.json` independently;
+2. identify which requested values are shared repository state and which are personal overrides;
+3. inspect repo instructions only when a conflict would change setup behavior;
+4. identify the host and available delivery evidence when runtime status matters.
 
-- Codex target: update `AGENTS.md`.
-- Claude target: update `CLAUDE.md` and `.claude/rules/freeflow-core.md`.
-- If only `AGENTS.md` exists, choose Codex.
-- If only `CLAUDE.md` exists, choose Claude.
-- If both exist and the user explicitly named the host target, update that host's files.
-- If both exist and the target is ambiguous, ask before editing.
-- If neither exists, ask which one to create.
-- Update both only when the user asks for multi-agent setup. Mention duplicated host activation drift risk.
+A valid repository config establishes activation. A missing local config inherits shared values. An invalid existing local config blocks effective Freeflow instead of falling back silently.
 
-Do not treat the current agent runtime alone as target approval. A Codex run in a repo that also has `CLAUDE.md` still needs the user to choose unless the request or repo instructions make the target explicit.
+If setup is already valid and no change was requested, preserve it and report the effective sources. Do not rewrite config merely to normalize formatting or materialize defaults.
 
-Update an existing `## Freeflow` block in place. Otherwise place the block near existing agent skill/workflow sections, or append near the end. Never duplicate it. Do not use `.codex/rules/*.rules` for Freeflow behavior; Codex rules are shell approval/security policy, not model memory.
+## Configure Shared Activation
 
-## Config
+For a new default setup, write:
 
-Create or update `.freeflow/config.json` using the config adapter in `references/activation-contract.md`.
-
-Minimal setup writes only `defaultMode`. Use `workflow` unless the user explicitly asks to persist a valid repo default: `conversation`, `workflow`, or `strict-workflow`.
-
-Ask one optional capabilities decision point after minimal host/config setup: whether to configure evidence routing and script transform adapters beyond the minimal default. If declined, keep the minimal setup path.
+```json
+{
+  "defaultMode": "workflow"
+}
+```
 
-If accepted, read `references/output-router-setup.md` and ask only path-changing follow-ups: router profile or intentional overrides, observed MCP/web/fetch/code-search producers to enable, persistence for each enabled producer/server, native safety-net policy, and whether to install global script transform adapters. Write high-level decisions and explicit overrides only. Do not add empty `outputRouter`, `observedRouting`, or `scriptTransform` objects, and do not dump effective defaults.
+During first activation, an explicitly requested `conversation` or `strict-workflow` mode becomes the shared repository default. Preserve valid existing settings and add no unrequested keys or empty sections.
 
-If the user consents to script transform setup, install adapters globally, not repo-locally. Resolve `../../router/dist/setup/script-transform-adapters.js` relative to this skill file and run:
+If repository config is invalid or conflicts with accepted source truth, use [Decision Gate](../decision-gate/SKILL.md) before replacing or reinterpreting it.
 
-```sh
-node <plugin-root>/router/dist/setup/script-transform-adapters.js install --config .freeflow/config.json
-```
+Do not create or append Freeflow instructions in `AGENTS.md`, `CLAUDE.md`, `.claude/rules/`, or another host-owned instruction surface.
 
-The installer uses `~/.cache/freeflow-script-adapters` by default, or `FREEFLOW_SCRIPT_TRANSFORM_ADAPTERS_HOME` when set. It installs JavaScript, jq, Python adapter packages, and a JSPI-capable `node@24` support runtime for Python, probes sandbox proofs, and writes `scriptTransform.enabled=true` with only proof-passing languages. Python/Eryx uses the setup-installed child Node process launched with `--experimental-wasm-jspi`; if that runtime cannot run the proofs, report the probe failure instead of claiming Python is enabled.
+## Add Personal Overrides Only When Requested
 
-If the user asks for router setup but gives no config knobs, say the router works with built-in defaults and ask which optional config they want persisted. Recommend no repo config unless they need observed routing, repo-specific hints, script transform setup, or safety-net behavior.
+Use `.freeflow/local.json` for an explicitly selected per-checkout override of `enabled`, `interactionContract`, `skills.enabled`, or `defaultMode`. Omitted values inherit from repository config and built-in defaults.
 
-Never enable observed routing or native safety-net routing by default. Observed routing requires explicit producer/server entries and a user-chosen persistence mode for each enabled entry. `outputRouter.postToolRouting: "safety-net"` requires an explicit request; `strict` is reserved and needs a separate confirmation before writing. Script transform may be enabled during setup only after explicit adapter-install/config consent and successful sandbox proof probing.
+In Pi, `/freeflow settings` edits personal overrides and `/freeflow settings repo` edits shared settings. Prefer those controls when available.
 
-Do not infer `strict-workflow` from "team", "strict gates", "careful", or high-risk examples. Recommend or ask unless the user explicitly says to make a mode the repo default.
+Before writing local config in a Git checkout, verify it is untracked and ignored. Do not modify shared ignore policy merely to store a personal preference; use the host's safe settings path or local Git exclusion. Refuse to overwrite a tracked local config.
 
-Do not add current mode, task, phase, file inventory, active plans, version metadata, activation file path, or unrequested router keys.
-Mode switches are task/conversation scoped unless the user explicitly asks to persist a different default mode.
+If local config is invalid, report that it blocks effective runtime. Repair or remove it only with authorization; never discard it and fall back silently.
 
-## Activation
+## Keep Optional Setup Explicit
 
-Render the canonical blocks from `references/activation-contract.md`.
+Do not ask an automatic capabilities question. Configure Output Router only when explicitly requested, using [Output Router setup](references/output-router-setup.md). Preserve valid existing capability config during idempotent setup.
 
-For Codex, put the Codex core block in `AGENTS.md`.
+## Establish Same-Turn Context
 
-For Claude, put only the Claude import block in `CLAUDE.md`, then put the Codex core block text in `.claude/rules/freeflow-core.md`. Do not create separate Claude rule files for `interview-gate` or `discover`; plugin runtime loads them.
+After successful verification, apply newly effective context directly for the remainder of the setup turn:
 
-Do not list the whole workflow, every mode, or full `interview-gate`/`discover` skill in always-loaded text. Do not split into multiple always-loaded Freeflow rule files unless the user explicitly confirms that split after the one-file recommendation.
+- read the [Interaction Contract](../../runtime/interaction-contract.md) when it is effective;
+- read [Workflow](../workflow/SKILL.md) and [Mode Contract](../mode-contract/SKILL.md) when Skills are effective;
+- read an explicitly configured capability skill only when runtime state says it is effective.
 
-## Do Not Create
+This direct read establishes same-turn guidance; it does not prove that a lifecycle adapter ran. After first activation, use [host setup](references/host-setup.md) to name the exact host-native lifecycle action for automatic delivery and resource refresh, state what applies before that boundary, and keep delivery confirmed, unavailable, or unconfirmed from evidence.
 
-Setup must not create empty `CONTEXT.md`, docs pages, repo-local hooks, state files, handoffs, skill inventories, `setup-output-router` skills, or `.codex/rules` behavior files.
-`CONTEXT.md` is domain language memory, not plugin state.
-Plugin-bundled context hooks are installed with Freeflow, not created by repo setup.
+## Verify And Report
 
-## Verify
+Verify:
 
-Before claiming setup is complete, check:
-- config JSON parses
-- minimal config contains only `defaultMode` with the requested explicit default, or `workflow` when no explicit default was requested
-- optional `outputRouter`, `observedRouting`, and `scriptTransform` config appears only after the capabilities decision point or explicit request, and contains only requested valid keys
-- observed routing, native safety-net routing, and script transform are off unless explicitly requested and supported
-- every enabled observed-routing producer/server has user-chosen persistence: `exact`, `metadata-only`, or `none`; setup does not offer or write `redacted`
-- Codex setup has exactly one `## Freeflow` block in `AGENTS.md`
-- Claude setup has exactly one `CLAUDE.md` import and one `.claude/rules/freeflow-core.md` core file
-- when script transform setup was accepted, global adapters were installed under the reported adapter home, `freeflow_status` shows available adapters, and `.freeflow/config.json` enables only proof-passing `scriptTransform.languages`
-- `.codex/rules` was not created or changed for Freeflow behavior
-- no unrelated files changed
+- repository config parses and contains a valid `defaultMode`;
+- local config is missing or valid, personal, untracked, and ignored when applicable;
+- effective `enabled`, Interaction Contract, Skills, and configured default values have the expected sources;
+- Skills-disabled mode remains resolved but dormant;
+- optional capability config changed only when requested;
+- no repo-owned host instructions or unrelated files changed.
 
-After successful setup verification, read `../mode-contract/SKILL.md`, `../workflow/SKILL.md`, `../interview-gate/SKILL.md`, `../discover/SKILL.md`, and `../output-router/SKILL.md` before the final response. Only say mode-contract, workflow, interview-gate, discover, and output-router context is loaded for this session if all five files were read successfully.
+Report separately:
 
-If verification cannot run, say what remains unverified.
+1. shared repository activation;
+2. personal override state and effective sources;
+3. effective capability state;
+4. same-turn direct context reads;
+5. automatic runtime delivery as **confirmed**, **unavailable**, or **unconfirmed**.