@hassangameryt/freeflow 0.1.0 → 0.3.0

package/plugins/freeflow/docs/architecture.md

@@ -1,86 +0,0 @@
-# Architecture
-
-Freeflow is a portable skill pack for coding agents.
-
-## Runtime Boundary
-
-Freeflow ships Markdown skills, bundled references, lightweight context-loading hooks, and a Pi extension. It does not ship a CLI, Codex/Claude native slash handlers, enforcement hooks, or a new agent runtime in v0.1.
-
-Host runtimes still control tools, sandboxing, approvals, and permissions. Freeflow controls workflow pressure:
-
-- how much clarification is needed
-- when artifacts are useful
-- when source-truth conflicts stop edits
-- when review and verification are required
-- when a handoff or durable decision is useful
-
-## Package Layout
-
-```text
-freeflow/
-  package.json
-  .agents/plugins/marketplace.json
-  .claude-plugin/marketplace.json
-  README.md
-  LICENSE
-  CHANGELOG.md
-  docs/
-  plugins/freeflow/
-    .codex-plugin/plugin.json
-    .claude-plugin/plugin.json
-    command-surface.json
-    hooks/
-    pi-extension/
-    skills/
-    docs/
-    evals/
-```
-
-The repository root is the marketplace and package-facing shell. Codex uses `.agents/plugins/marketplace.json`; Claude uses `.claude-plugin/marketplace.json`. Both point at `plugins/freeflow/`. Pi uses the root `package.json` `pi` manifest to load `plugins/freeflow/skills/` and `plugins/freeflow/pi-extension/index.js`.
-
-`plugins/freeflow/` is the single runtime source of truth. Skill edits, bundled references, eval metadata, and command-surface metadata live there to avoid generated package drift.
-
-## Progressive Disclosure
-
-Each skill keeps its active `SKILL.md` short. Stable details move into `references/` files only when they prevent bloat, reduce repeated work, or address measured failures.
-
-This keeps the model's first-loaded instructions focused on behavior:
-
-- trigger
-- loop
-- stop condition
-- failure prevention
-
-## Host Setup
-
-`setup-freeflow` installs a compact always-on contract into the host repo.
-
-The canonical setup contract lives in `skills/setup-freeflow/references/activation-contract.md`; setup docs, fixtures, and eval assertions should reference it or be checked against it.
-
-Codex setup targets `AGENTS.md` and `.freeflow/config.json`.
-
-Claude setup targets `CLAUDE.md`, `.claude/rules/freeflow-core.md`, and `.freeflow/config.json` when Claude is the selected host.
-
-Setup should not silently update both hosts or overwrite stronger repo-specific rules. Existing repo instructions are source truth.
-
-## Runtime Context Hooks
-
-The installed plugin owns `hooks/hooks.json`. Setup does not copy hook files into target repos.
-
-The hooks load the existing `workflow` skill, workflow map, and `interview-gate` skill:
-
-- at session start, including startup, resume, clear, and compact
-
-They also report whether the current repo appears set up, partially set up, or missing setup. They do not run after edit/write tools, block tools, grant permissions, enforce mode policy, or replace repo instructions.
-
-Setup handles the same-session case directly: after successful setup verification, it reads the workflow skill, workflow map, and interview-gate skill before its final response and only then says workflow and interview-gate context is loaded.
-
-Host runtimes may require plugin hooks to be reviewed and trusted after install. If the host skips untrusted hooks, setup still writes activation/config files, but future session-start runtime context will not load until hooks are trusted and the session is restarted, resumed, cleared, or compacted.
-
-Pi uses an extension instead of `hooks/hooks.json`. The Pi extension registers direct commands, reads `workflow/SKILL.md`, `workflow/references/workflow-map.md`, and `interview-gate/SKILL.md`, refreshes that context on `session_start` and `session_compact`, and injects it during Pi's `before_agent_start` lifecycle event. Pi `/workflow` commands set a session-scoped current-mode override, while `.freeflow/config.json` remains the default-mode source. It follows the same boundary as the Codex/Claude hooks: context loading only, no enforcement.
-
-## Deferred Enforcement
-
-Enforcement hooks and CLI checks are intentionally deferred. They are useful only after skill wording and evals prove a repeated behavior needs mechanical enforcement.
-
-For v0.1, commands are model-routed language such as `/write-spec` or `/verify-work`; they are not native registered slash handlers.

package/plugins/freeflow/docs/release-evidence.md

@@ -1,49 +0,0 @@
-# Release Evidence
-
-Freeflow v0.1 is based on local fixture evals and release acceptance runs from the development repository.
-
-## Acceptance Summary
-
-The local v0.1 acceptance suite passed after measured fixes and was rerun during prepublish verification on 2026-05-26.
-
-High-signal behaviors covered:
-
-- Source-truth conflicts stop before edits.
-- Strict public API specs ask for owner decisions.
-- Execution stops when verification reveals a bad plan.
-- Commit flow refuses mixed staged sensitive changes.
-- Decision capture asks before inventing memory conventions.
-- Bypass skips ceremony, not judgment.
-
-## Command Surface
-
-The development registry covers:
-
-- 4 mode commands.
-- 13 direct workflow skill calls.
-- 2 contributor skill calls.
-
-Codex/Claude native slash handlers are not shipped in v0.1. In those hosts, commands are model-routed through natural language and skill activation. Pi registers direct Freeflow commands through its extension.
-
-## Runtime Context
-
-Freeflow ships plugin-bundled context hooks that load the existing `workflow` skill, workflow map, and `interview-gate` skill at session start. These hooks do not run after edit/write tools, enforce behavior, block tools, or create repo-local hook files.
-
-For the same session that runs setup, `setup-freeflow` reads the workflow skill, workflow map, and interview-gate skill after successful setup verification before saying workflow and interview-gate context is loaded.
-
-Host trust prompts for plugin hooks are expected host behavior. Local metadata validation checks hook packaging and deterministic output, not end-to-end host trust UI.
-
-## Release Metadata
-
-Run `plugins/freeflow/evals/scripts/validate-release-metadata.sh` for local prepublish checks across marketplace metadata, host manifests, command-surface routing, release-boundary docs, package cleanliness, and deferred install-smoke status.
-
-Run `plugins/freeflow/evals/scripts/check-runtime-context-hook.sh` after changing lifecycle context hooks.
-
-## Known Deferred Work
-
-- Live Claude smoke evals after Hassan confirms Claude testing is available again.
-- GitHub-install smoke tests in separate Codex, Claude, and fresh Pi environments.
-- Enforcement hooks or CLI checks only after repeated behavior failures justify them.
-- Public marketplace submission only after GitHub install works for required hosts.
-
-Full eval reports are development evidence and are not included in the runtime package.

package/plugins/freeflow/pi-extension/index.js

@@ -1,250 +0,0 @@
-import { readFile } from "node:fs/promises";
-import { join } from "node:path";
-
-const VALID_MODES = new Set(["conversation", "workflow", "strict-workflow"]);
-
-const WORKFLOW_COMMANDS = [
-  "grill-context",
-  "research-brief",
-  "write-spec",
-  "review-artifact",
-  "write-plan",
-  "execute-plan",
-  "diagnose-failure",
-  "verify-work",
-  "review-work",
-  "commit-work",
-  "capture-decisions",
-  "handoff",
-  "bypass",
-];
-
-const CONTRIBUTOR_COMMANDS = [
-  "setup-freeflow",
-  "write-skill",
-  "evaluate-skill",
-];
-
-const MODE_STATE_ENTRY = "freeflow-mode";
-const RESET_MODE_ARGS = new Set(["reset"]);
-
-let runtimeContextCache = null;
-let currentModeOverride = null;
-
-async function loadRuntimeContext() {
-  const [workflowSkill, workflowMap, interviewGateSkill] = await Promise.all([
-    readFile(new URL("../skills/workflow/SKILL.md", import.meta.url), "utf8"),
-    readFile(new URL("../skills/workflow/references/workflow-map.md", import.meta.url), "utf8"),
-    readFile(new URL("../skills/interview-gate/SKILL.md", import.meta.url), "utf8"),
-  ]);
-
-  return { workflowSkill, workflowMap, interviewGateSkill };
-}
-
-async function refreshRuntimeContext() {
-  runtimeContextCache = await loadRuntimeContext();
-  return runtimeContextCache;
-}
-
-async function getRuntimeContext() {
-  if (runtimeContextCache) {
-    return runtimeContextCache;
-  }
-  return refreshRuntimeContext();
-}
-
-async function readDefaultMode(cwd) {
-  try {
-    const raw = await readFile(join(cwd, ".freeflow/config.json"), "utf8");
-    const parsed = JSON.parse(raw);
-    return VALID_MODES.has(parsed.defaultMode) ? parsed.defaultMode : "workflow";
-  } catch {
-    return "workflow";
-  }
-}
-
-function restoreModeOverride(ctx) {
-  currentModeOverride = null;
-  const entries = ctx.sessionManager?.getEntries?.() ?? [];
-
-  for (const entry of entries) {
-    if (entry.type !== "custom" || entry.customType !== MODE_STATE_ENTRY) {
-      continue;
-    }
-
-    const mode = entry.data?.currentMode;
-    currentModeOverride = VALID_MODES.has(mode) ? mode : null;
-  }
-}
-
-async function readModeState(cwd) {
-  const defaultMode = await readDefaultMode(cwd);
-  const currentMode = VALID_MODES.has(currentModeOverride) ? currentModeOverride : null;
-  return {
-    defaultMode,
-    currentMode,
-    effectiveMode: currentMode ?? defaultMode,
-  };
-}
-
-function setModeStatus(ctx, modeState) {
-  ctx.ui.setStatus("freeflow", `freeflow: ${modeState.effectiveMode}`);
-}
-
-function describeModeState(modeState) {
-  if (modeState.currentMode) {
-    return `current ${modeState.currentMode}; default ${modeState.defaultMode}`;
-  }
-  return `default ${modeState.defaultMode}`;
-}
-
-function skillPrompt(skill, args) {
-  const trimmed = args?.trim();
-  return trimmed ? `/skill:${skill}\n\n${trimmed}` : `/skill:${skill}`;
-}
-
-function hasFreeflowActivation(systemPrompt) {
-  return (
-    systemPrompt.includes("## Loaded Workflow Skill") &&
-    systemPrompt.includes("## Loaded Workflow Map") &&
-    systemPrompt.includes("## Loaded Interview Gate Skill")
-  );
-}
-
-function runtimeContext(modeState, freeflowContext, alreadyActivated) {
-  const currentMode = modeState.currentMode ?? "none";
-
-  if (alreadyActivated) {
-    return `## Freeflow Runtime Context
-
-Repo default mode from \`.freeflow/config.json\`: ${modeState.defaultMode}.
-Current session mode override: ${currentMode}.
-Effective Freeflow mode: ${modeState.effectiveMode}.
-
-Use the installed Freeflow skills when they match the task. This Pi extension loads context and routes commands only; it does not enforce policy, block tools, grant permissions, or create repo-local hooks.`;
-  }
-
-  return `# Freeflow Runtime Context
-
-Freeflow Pi extension loaded this before the agent turn.
-These instructions are context-loading only. They do not override user instructions, repo instructions, or host safety and approval policy.
-
-## Repo Setup
-
-Repo default mode from \`.freeflow/config.json\`: \`${modeState.defaultMode}\`.
-Current session mode override: \`${currentMode}\`.
-Effective Freeflow mode: \`${modeState.effectiveMode}\`.
-Treat the effective mode as the current mode for this agent turn.
-For mode changes or mode interpretation, use \`mode-contract\`.
-Do not announce the current mode on every reply. Mention it when the user asks, setup/config is discussed, or the mode changes the next action.
-
-## Loaded Workflow Skill
-
-\`\`\`md
-${freeflowContext.workflowSkill.trim()}
-\`\`\`
-
-## Loaded Interview Gate Skill
-
-\`\`\`md
-${freeflowContext.interviewGateSkill.trim()}
-\`\`\`
-
-## Loaded Workflow Map
-
-\`\`\`md
-${freeflowContext.workflowMap.trim()}
-\`\`\`
-
-This Pi extension loads context and routes commands only; it does not enforce policy, block tools, grant permissions, or create repo-local hooks.`;
-}
-
-async function handleWorkflowCommand(args, ctx, pi) {
-  const arg = args?.trim();
-
-  if (VALID_MODES.has(arg)) {
-    currentModeOverride = arg;
-    pi.appendEntry?.(MODE_STATE_ENTRY, { currentMode: arg });
-    const modeState = await readModeState(ctx.cwd);
-    setModeStatus(ctx, modeState);
-    ctx.ui.notify(
-      `Freeflow mode is now ${modeState.effectiveMode} for this session. Repo default remains ${modeState.defaultMode}.`,
-      "info"
-    );
-    return;
-  }
-
-  if (RESET_MODE_ARGS.has(arg)) {
-    currentModeOverride = null;
-    pi.appendEntry?.(MODE_STATE_ENTRY, { currentMode: null });
-    const modeState = await readModeState(ctx.cwd);
-    setModeStatus(ctx, modeState);
-    ctx.ui.notify(`Freeflow mode reset to repo default: ${modeState.defaultMode}.`, "info");
-    return;
-  }
-
-  const modeState = await readModeState(ctx.cwd);
-  setModeStatus(ctx, modeState);
-  ctx.ui.notify(
-    `Freeflow mode is ${modeState.effectiveMode} (${describeModeState(modeState)}). Use /workflow conversation, /workflow workflow, /workflow strict-workflow, or /workflow reset.`,
-    "info"
-  );
-}
-
-export default function freeflow(pi) {
-  pi.on("session_start", async (_event, ctx) => {
-    restoreModeOverride(ctx);
-    const [modeState] = await Promise.all([readModeState(ctx.cwd), refreshRuntimeContext()]);
-    setModeStatus(ctx, modeState);
-  });
-
-  pi.on("session_compact", async (_event, ctx) => {
-    const [modeState] = await Promise.all([readModeState(ctx.cwd), refreshRuntimeContext()]);
-    setModeStatus(ctx, modeState);
-  });
-
-  pi.on("before_agent_start", async (event, ctx) => {
-    const [modeState, freeflowContext] = await Promise.all([
-      readModeState(ctx.cwd),
-      getRuntimeContext(),
-    ]);
-    setModeStatus(ctx, modeState);
-    return {
-      systemPrompt:
-        event.systemPrompt +
-        "\n\n" +
-        runtimeContext(modeState, freeflowContext, hasFreeflowActivation(event.systemPrompt)),
-    };
-  });
-
-  for (const skill of WORKFLOW_COMMANDS) {
-    pi.registerCommand(skill, {
-      description: `Run Freeflow ${skill}`,
-      handler: async (args) => {
-        await pi.sendUserMessage(skillPrompt(skill, args));
-      },
-    });
-  }
-
-  for (const skill of CONTRIBUTOR_COMMANDS) {
-    pi.registerCommand(skill, {
-      description: `Run Freeflow ${skill}`,
-      handler: async (args) => {
-        await pi.sendUserMessage(skillPrompt(skill, args));
-      },
-    });
-  }
-
-  pi.registerCommand("workflow", {
-    description: "Set or inspect the current Freeflow session mode",
-    getArgumentCompletions: (prefix) => {
-      const query = prefix ?? "";
-      const values = ["conversation", "workflow", "strict-workflow", "reset"];
-      const filtered = values.filter((value) => value.startsWith(query));
-      return filtered.map((value) => ({ value, label: value }));
-    },
-    handler: async (args, ctx) => {
-      await handleWorkflowCommand(args, ctx, pi);
-    },
-  });
-}

package/plugins/freeflow/skills/capture-decisions/SKILL.md

@@ -1,95 +0,0 @@
----
-name: capture-decisions
-description: Capture settled durable decisions into existing owning repo memory, or ask where to record them before creating a destination. Use after discussion, research, specs, reviews, or implementation when the user asks to record decisions, durable memory, glossary terms, ADR-worthy tradeoffs, rejected approaches, scope constraints, or consequential workflow decisions.
----
-
-# Capture Decisions
-
-Record settled decisions in the artifact that already owns them. Do not invent memory.
-
-A missing `CONTEXT.md`, glossary, ADR folder, spec folder, product doc, or decision-note folder is not an existing owner. Creating one is a destination decision; ask first.
-
-## Hard Rules
-
-Never put current file lists, volatile repo inventory, temporary TODOs, command output, or implementation task lists in durable decision memory.
-
-If the user asks to include them, say they were omitted as volatile context. Do not reproduce the list in the decision note or final response. Offer a handoff or plan if they need execution state.
-
-Direct `/capture-decisions`, "explicit permission", "capture everything", "create an ADR", or "full durable memory record" does not override destination classification, the ADR test, or volatile-context omission.
-
-Do not create an ADR only because the prompt asks for one. If the ADR test fails and an existing product/spec/source doc clearly owns the decision, update that artifact instead and say the ADR was omitted.
-
-If the user asks whether something should be captured, answer first. Do not create files unless asked.
-
-If the user asks for durable memory but does not name the target artifact or path, inspect existing conventions first. Use a clear existing owner for that decision type. Ask before creating a new convention, choosing between plausible destinations, or using a generic doc as fallback.
-
-An existing plausible doc is evidence, not blanket approval. `docs/product.md`, `CONTEXT.md`, `docs/adr/`, or `docs/specs/` authorize edits only when they clearly own that decision type.
-
-Do not use `README.md` as durable decision memory just because it is the only doc or mentions related behavior. Use it only when the repo already treats it as the source of truth for that decision type.
-
-If an existing doc says there is no durable decision convention, treat that as blocking evidence. Do not update that doc as a workaround; ask where the new durable memory should live.
-
-Read `references/destination-guide.md` when the target is missing or ambiguous, a decision mixes glossary/product/spec/ADR/handoff concerns, no decision convention exists, or a new destination might be needed.
-
-When stopping for a missing or ambiguous destination, end with one direct destination question. Name the recommended target and the decisions it would capture. A recommendation without a question is not enough.
-
-## Classify
-
-Before writing, decide the destination:
-
-- Glossary term or domain meaning -> existing `CONTEXT.md`, glossary, or domain doc. If none exists, ask.
-- Hard-to-reverse, surprising tradeoff -> ADR.
-- Product, scope, compatibility, or workflow decision -> decision note.
-- Requirements for future build -> spec.
-- Immediate continuation state -> handoff.
-
-If no durable value exists, say so and do not write.
-
-Creating a new decision-note convention is a destination decision. If the repo has no existing decision-note convention, ask before creating `docs/decisions/`.
-
-If no existing artifact clearly owns the decision, ask before writing. If more than one destination could fit, ask before writing. This includes choosing between an existing product/spec doc, a new decision note, a glossary, README, or an ADR.
-
-## ADR Test
-
-Use an ADR only when all are true:
-
-- Hard to reverse.
-- Surprising without context.
-- Chosen from real alternatives.
-
-Otherwise use a lighter decision note or update the relevant existing artifact.
-
-## Write Shape
-
-When creating a durable decision artifact, follow the compact identity guidance in `../write-spec/references/artifact-standards.md` if future agents or teammates will rely on it.
-
-Keep decision notes short:
-
-```text
-# Decision: ...
-
-Date: ...
-
-## Decision
-...
-
-## Rationale
-...
-
-## Consequences
-...
-
-## Not Captured
-...
-```
-
-Link to live evidence. Do not duplicate volatile facts.
-
-## Stop Conditions
-
-Stop and ask before writing when:
-
-- The decision is not actually settled.
-- The destination is ambiguous.
-- Capturing would change product, scope, policy, ADRs, specs, or source truth.
-- The user asks for memory but not its durability or location.

package/plugins/freeflow/skills/capture-decisions/references/destination-guide.md

@@ -1,65 +0,0 @@
-# Destination Guide
-
-Use this when the durable-memory destination is not obvious.
-
-## Destination Test
-
-Before writing, answer:
-
-- What settled decision is being recorded?
-- Which existing artifact is already the source of truth for that kind of decision?
-- Would this edit create a new documentation convention or source of truth?
-- Would a future agent treat the target as authority for this decision?
-
-If the owner is unclear, ask before writing.
-
-## Common Destinations
-
-| Decision type | Prefer | Do not use |
-| --- | --- | --- |
-| Domain term or glossary meaning | Existing `CONTEXT.md`, glossary, or domain doc; otherwise ask | README as a fallback glossary; creating `CONTEXT.md` without asking |
-| Product behavior, scope, compatibility, billing, privacy, or policy | Existing product/spec/policy doc; otherwise ask where to capture | ADR unless the ADR test passes |
-| Hard-to-reverse, surprising tradeoff chosen from alternatives | ADR | Product notes for architecture that needs rationale |
-| Future build requirements | Existing or requested spec | Handoff or decision note as a hidden spec |
-| Immediate continuation state, next steps, file inventory, commands, partial progress | Handoff or plan | Durable decision memory |
-| Rejected approach | ADR if tradeoff-heavy; otherwise decision note or relevant spec section | Changelog or README by default |
-| Workflow/process convention | Existing agent/process doc | New global standard without asking |
-
-## Ambiguity Rules
-
-- No destination convention means ask; it does not authorize `docs/decisions/`.
-- A missing `CONTEXT.md`, glossary, ADR directory, spec directory, product doc, or decision-note folder is not a destination convention.
-- The only existing doc is not automatically the right doc.
-- `README.md` is a project overview unless the repo clearly treats it as the authoritative product/domain/process source.
-- If `README.md` or another doc says there is no durable decision convention, do not edit it to create one implicitly.
-- `CONTEXT.md` is for stable project language and domain meaning, not implementation summaries or task state.
-- Handoffs preserve continuation memory. They are not authority for product, policy, or architecture.
-
-Ask one focused question and recommend the narrowest durable destination supported by the repo. The final sentence should be the question, for example: `Should I create CONTEXT.md to record the RiskReview domain term and the automated retry scheduling scope boundary?`
-
-## Decision Artifact Shape
-
-For a new durable decision artifact, use the compact identity guidance in `../../write-spec/references/artifact-standards.md` when the artifact is team-facing, strict-workflow, or future-agent-facing.
-
-Keep the note short:
-
-```md
-# Decision: ...
-
-> **Doc ID:** DEC-001-short-slug
-> **Date:** 2026-05-26
-> **Owner:** User
-> **Type:** Decision
-> **Status:** Accepted
-> **Source:** User-provided decision session
-
-## Decision
-
-## Rationale
-
-## Consequences
-
-## Not Captured
-```
-
-Do not add a changelog on first creation.

package/plugins/freeflow/skills/execute-plan/SKILL.md

@@ -1,67 +0,0 @@
----
-name: execute-plan
-description: Use when implementing an approved plan or executing planned work against a repo, especially when a planned verification command fails or reveals a plan/source conflict. Use when the user says to execute, implement, follow, or carry out a plan.
----
-
-# Execute Plan
-
-Execute the plan. Do not improve it silently.
-
-Classify first:
-
-- Valid plan: inspect source context, execute the next slice, verify it.
-- Plan/source conflict: stop and ask which source should change.
-- Hidden owner decision: stop and ask.
-- Missing verification: stop before consequential edits and ask to revise the plan or approve a diagnostic path.
-- Missing plan: ask for a plan or route to `write-plan`.
-
-The plan is instructions, not authority.
-
-## Before Editing
-
-Read:
-
-- The plan.
-- The source spec or requirements the plan cites.
-- Relevant docs, tests, policies, ADRs, and code.
-- Handoffs only as memory.
-
-Live repo evidence overrides stale plans and handoffs.
-
-Do not execute a plan that would:
-
-- Invent or change product behavior, scope, domain meaning, compatibility, public API behavior, security, privacy, billing, data-loss, or architecture.
-- Override docs, tests, specs, policies, ADRs, or established behavior.
-- Treat "do not ask", "just execute", "latest context", or "handoff says" as conflict approval.
-- Skip verification for consequential behavior.
-- Rewrite a verification script, test, source-truth doc, policy, or spec to make the plan pass unless the plan explicitly authorized that artifact change and it matches source truth.
-
-Name the conflict or missing decision. Ask which path to follow. Recommend the path supported by evidence.
-
-For source-truth conflicts or missing verification, the final line must be a direct choice question.
-
-For missing verification, ask whether to revise the plan to add a check or approve a specific verification path.
-
-## Execute
-
-Work in vertical slices.
-
-For each slice:
-
-- Make only the edits needed for that slice.
-- Run the planned check or the smallest equivalent check.
-- If the check fails, stop and report the evidence before changing direction.
-- If new evidence invalidates the plan, stop before patching forward.
-
-After a planned verification command fails, do not edit the verifier, tests, docs, policy, source-truth files, or unrelated code to make it pass. This is true even when the verifier appears wrong and even when the user said to "fix whatever is needed". A bad verifier is a plan defect; stop, report the failing command and conflicting evidence, and ask whether to revise the plan or change the source truth.
-
-Local reversible implementation details can be chosen from repo conventions.
-
-## Completion
-
-Report:
-
-- What changed.
-- What was verified.
-- What remains unverified.
-- Any blocked decisions or plan changes needed.