@hassangameryt/freeflow 0.3.0 → 0.5.0

package/plugin-docs/workflow.md

@@ -1,57 +0,0 @@
-# Workflow
-
-Freeflow is a workflow layer, not a new agent. It helps the agent choose the right amount of process for the task.
-
-## Modes
-
-- `conversation`: non-mutating discussion, read-only exploration, and planning in chat; edits or other state-changing work require switching to `workflow` or `strict-workflow` first.
-- `workflow`: default for consequential work; use the workflow spine and scale detail to risk.
-- `strict-workflow`: high-risk or hard-to-reverse work with stronger gates.
-
-Use strict-workflow for security, privacy, billing, public APIs, migrations, data loss, compatibility, permissions, deployment, or irreversible architecture.
-
-## Map
-
-```mermaid
-flowchart LR
-  Request{request}
-  Talk[conversation<br/>answer directly]
-  Discover[discover<br/>checkpoint]
-  Spec[spec]
-  Plan[plan]
-  Build[build<br/>execute / diagnose]
-  Check[review + verify]
-  Close[commit / handoff]
-
-  Request -->|question| Talk
-  Request -->|work| Discover
-  Discover --> Spec --> Plan --> Build --> Check --> Close
-  Check -. new evidence or failed check .-> Discover
-```
-
-The map is orienting, not mandatory. Small reversible work can skip unnecessary artifacts and gates. Use `/discover` for the discovery loop.
-
-## Backward Edge
-
-Loop back when new evidence changes the path:
-
-```mermaid
-flowchart LR
-  Trigger{new evidence<br/>conflict<br/>failed check<br/>owner decision}
-  Decide{changes<br/>next action?}
-  Continue[continue]
-  Reenter[clarify / discover<br/>revise spec or plan<br/>diagnose / split / stop]
-
-  Trigger --> Decide
-  Decide -->|no| Continue
-  Decide -->|yes| Reenter
-  Reenter -. resume .-> Decide
-```
-
-The agent should not silently choose the backward destination when the choice changes product behavior, scope, compatibility, public APIs, security, privacy, billing, data loss, permissions, or irreversible architecture.
-
-## Bypass
-
-Bypass skips ceremony, not judgment.
-
-Use `bypass` only to skip an unnecessary gate. It does not skip user-owned decisions, source-truth conflicts, risky checks, or fresh verification before completion claims.

package/skills/diagnose-failure/references/feedback-loop-catalog.md

@@ -1,25 +0,0 @@
-# Feedback Loop Catalog
-
-Pick the smallest loop that proves the user's failure. Prefer loops the agent can run repeatedly.
-
-## Common Loops
-
-- Failing test: best when an existing seam reaches the bug.
-- Repro command: CLI, script, package task, or one exact command with fixture input.
-- HTTP script: one request or short request sequence against a local service.
-- Browser script: UI flow with DOM, console, and network assertions.
-- Captured trace: HAR, log slice, event payload, seed, screenshot timestamp, core dump, or production sample replayed locally.
-- Throwaway harness: minimal script around the real module when no test framework exists.
-- Differential loop: same input through old versus new code, config, dataset, or dependency version.
-- Instrumented run: targeted logs or counters at boundaries that distinguish hypotheses.
-
-## Loop Quality
-
-Improve the loop before fixing:
-
-- Faster: remove unrelated startup and setup.
-- Sharper: assert the exact symptom, not generic success.
-- More deterministic: pin time, seed randomness, isolate network and filesystem.
-- More representative: use the reported input shape and environment boundary.
-
-If none is possible, stop and ask for the smallest missing artifact: command, logs, trace, failing input, screenshot with timestamp, environment access, or permission for temporary instrumentation.

package/skills/discover/ARTIFACT-DESTINATIONS.md

@@ -1,58 +0,0 @@
-# Artifact Destinations
-
-Use this when a discovery checkpoint or decision must survive beyond chat.
-
-## Destination Test
-
-Before writing, answer:
-
-- What needs to survive?
-- Who will treat the destination as authority?
-- Which existing artifact already owns this kind of truth?
-- Would writing here create a new convention?
-- Would a future agent know to look here?
-
-If the owner is unclear, ask before writing.
-
-## Common Destinations
-
-| Discovery output | Prefer | Avoid |
-| --- | --- | --- |
-| Domain term or meaning | Existing `CONTEXT.md`, glossary, or domain doc | README fallback; creating domain memory without asking |
-| Feature behavior, scope, acceptance | Existing or requested spec | ADR unless the ADR test passes |
-| Future implementation path | Plan | Hidden plan inside a discovery note |
-| Evidence summary before requirements settle | Existing discovery, research, or design notes; otherwise ask | Creating `docs/research/` by default |
-| Immediate continuation state | Handoff | Durable decision memory |
-| Hard-to-reverse surprising tradeoff from alternatives | ADR | Product note that hides rationale |
-| Rejected approach | ADR if tradeoff-heavy; otherwise spec/decision note | Changelog or README by default |
-| No durable value | Chat checkpoint | New file for ceremony |
-
-## ADR Test
-
-Use an ADR only when all are true:
-
-- Hard to reverse.
-- Surprising without context.
-- Chosen from real alternatives.
-
-Otherwise use the owning spec, decision note, domain doc, handoff, or chat.
-
-## Stop Rules
-
-Do not create a new `CONTEXT.md`, glossary, `docs/decisions/`, `docs/specs/`, `docs/research/`, or ADR folder just because the checkpoint needs memory.
-
-A missing destination convention is a decision point.
-
-Do not put volatile file lists, command output, temporary TODOs, or implementation inventory in durable decision memory. Put continuation state in a handoff or plan when needed.
-
-## Question Shape
-
-When destination is ambiguous, ask one direct question:
-
-```text
-I have a checkpoint worth preserving: [what].
-The narrowest destination is [recommended artifact] because [why].
-Should I save it there?
-```
-
-Do not write the artifact before the user chooses the destination.

package/skills/discover/CHECKPOINTS.md

@@ -1,74 +0,0 @@
-# Discovery Checkpoints
-
-A checkpoint is the output of discovery. It preserves the current understanding and names the next route.
-
-Discovery does not end by silently writing a spec, plan, or implementation.
-
-## Chat Or Artifact
-
-Keep the checkpoint in chat when the work is short-lived and the next turn can safely continue from conversation context.
-
-Save the checkpoint when it must guide later work, another agent, a future session, or a durable artifact.
-
-Use the narrowest owning artifact:
-
-- Spec: behavior, scope, requirements, acceptance, product decisions.
-- Plan: future implementation path and checks.
-- Handoff: immediate continuation state.
-- Decision note or ADR: durable tradeoff or rejected approach.
-- Domain memory: stable term or domain meaning.
-- Discovery note: evidence summary that must be reused before requirements are settled.
-
-If no clear destination exists, ask before writing.
-
-## Shape
-
-Use this shape. Omit sections that do not apply.
-
-```text
-Question / goal: ...
-Evidence: ...
-Current understanding: ...
-Settled: ...
-Tentative: ...
-Open: ...
-Recommendation: ...
-Next: Forward | Backward | Branch | Stop — ...
-```
-
-## Good Checkpoints
-
-A good checkpoint:
-
-- Links or names live evidence instead of copying volatile inventory.
-- Separates settled facts from tentative assumptions.
-- Names open decisions that change the next route.
-- Recommends the next route without treating it as permission.
-- Avoids hiding user-owned decisions in polished prose.
-
-## Bad Checkpoints
-
-Bad:
-
-```text
-We discussed a lot. I'll implement the recommended path.
-```
-
-because it skips settled/tentative/open state and jumps to action.
-
-Bad:
-
-```text
-Decision: create docs/decisions/ and record everything.
-```
-
-when the repo has no decision-note convention and the user has not chosen that destination.
-
-Good:
-
-```text
-Settled: RiskReview is manual today; $500+ invoices enter review.
-Tentative: retry scheduling should assist support, not replace review.
-Open: should this be support-assistive or fully automated?
-Next: Backward — answer the automation-scope decision before spec.
-```

package/skills/discover/SKILL.md

@@ -1,173 +0,0 @@
----
-name: discover
-description: Use before the first answer or repo/code exploration when the user is shaping an idea, feature, tool/API surface, runtime behavior, architecture direction, vague task, bug-like unknown, or consequential hypothesis/question before spec, plan, build, or durable memory. Trigger especially on "should we", "why not", "what do you think", or design questions.
----
-
-# Discover
-
-Discover is the context-building loop before action: evidence-guided discussion that finds the next high-leverage decision and ends in a checkpoint.
-
-If this skill matches, load it before the first repo search, code read, web lookup, command, design answer, or artifact. Direct questions still use discovery-light: inspect the smallest relevant evidence, then answer directly.
-
-Priority: Interview Gate stops silent decisions and user-owned decisions first. Discover handles context-building after no immediate stop condition remains. Output Router only chooses evidence transport after the workflow/discovery route is clear.
-
-Do not turn discovery into a questionnaire, a report by default, or a decision-capture script. The hard part is shared understanding, not filling an artifact.
-
-For short-lived work, keep the checkpoint in chat. When it must guide later work, save it in the narrowest owning artifact: spec, plan, handoff, decision note, ADR, domain memory, or discovery note.
-
-Goal: enough evidence and shared understanding to route to spec, plan, more discovery, durable memory, build, or stop without inventing product, domain, scope, public API, security, privacy, billing, data-loss, compatibility, or architecture decisions.
-
-Hard stop: do not satisfy requests for “every question,” “grill me,” “25-50 questions,” or recommended answers for each question. That creates an approval script. Inspect evidence, name the decision tree, and ask the next one or two path-changing questions instead.
-
-## Evidence Before Questions
-
-Inspect first when the answer is discoverable:
-
-- code, tests, docs, ADRs, specs, policies, issues, logs, traces, or current repo state;
-- provided files, URLs, screenshots, transcripts, or user context;
-- current external docs or web sources when framework/library facts, ecosystem behavior, or recent changes matter.
-
-Ask before inspecting only when multiple targets would change the discovery path or when access/scope is user-owned.
-
-For a direct question, keep the loop light:
-
-```text
-question -> inspect smallest relevant evidence -> answer directly
-```
-
-No artifact, plan, or checkpoint is required unless the answer changes future consequential work.
-
-## Design Pressure
-
-Use `../design-for-depth/SKILL.md` when discovery shapes modules, interfaces, seams, adapters, architecture direction, growing scope, codebase exploration, or repeated review/execution churn.
-
-Do not decide architecture up front just because the lens is active. Use it to notice whether complexity is being hidden behind useful interfaces or spread across callers, tests, docs, artifacts, and future agents.
-
-Use the deletion test on questions and decisions: if skipping it makes complexity spread downstream, it matters. If skipping it makes complexity vanish, it was ceremony.
-
-## Scope Framing
-
-Preserve the user's intended scope. Do not silently turn a large idea into `v1`/`v2`, MVP, release, or roadmap framing.
-
-Use implementation slices, implementation phases, checklists, or multiple artifacts to make large work understandable and executable without changing what the user asked for.
-
-Versioned shipping is a product/scope decision. Use it only when the user asks for release planning, the source context already uses that framing, or you have named why release boundaries matter and the user agrees.
-
-If the full scope is too large for one safe pass, say that directly. Recommend implementation slices or artifact splits first; recommend versioned releases only when that is the user's actual problem.
-
-## Loop
-
-1. Identify the target: repo area, artifact, URL, product, model, package, paper, issue, symptom, or idea. If multiple plausible targets would change discovery, ask for the source.
-2. Inspect the smallest evidence that can change the current route.
-3. Explain the current understanding in plain language.
-4. Brainstorm or compare paths when the direction is still forming; do not force a decision too early.
-5. Ask one path-changing question when the answer would change the next artifact or action.
-6. Let the user challenge, counter-question, or add constraints. Treat that as discovery input, not interruption.
-7. Refresh evidence when new claims, conflicts, or branches appear.
-8. Track decisions as settled, tentative, or open.
-9. Stop when remaining ambiguity would not change the next route.
-
-Discovery may move through evidence, brainstorming, targeted questioning, design, and checkpointing in any order. Do not force a fixed sequence when the evidence or conversation needs a loop.
-
-## Final Question Pass
-
-Before routing from discovery to `write-spec`, run a final ambiguity sweep.
-
-Trigger it when:
-
-- the user asks to write the spec;
-- the user says brainstorming, discovery, or discussion feels complete;
-- the user asks to move to the next phase;
-- you are about to close discovery with `Next: Forward — write-spec`.
-
-Ask the smallest set of remaining path-changing questions whose answers would affect spec scope, product behavior, acceptance, public API, architecture, security, privacy, billing, data-loss, compatibility, or artifact destination.
-
-If meaningful ambiguity remains, route with `Next: Forward — final question pass before write-spec` and ask those questions. If no meaningful questions remain, say so and route to `write-spec`.
-
-Do not use this while brainstorming, research, or comparison is still active. Do not turn it into a long questionnaire or recommendation approval script.
-
-## Question Discipline
-
-Prefer deeper questions over more questions. Ask as many as the situation needs, but each question should earn its place.
-
-Before asking, run the deletion test:
-
-```text
-If I do not ask this, does downstream complexity spread?
-```
-
-If no, skip it.
-
-Bad question:
-
-```text
-Should the button be blue or green?
-```
-
-when the feature purpose is still unclear.
-
-Good question:
-
-```text
-Is this for one workflow or many workflows?
-```
-
-because it changes the module interface, spec shape, and test surface.
-
-Long question chains are a failure mode, not diligence. Never number out a long list just because the user asked for one.
-
-Do not turn recommendations into an approval script. Recommendations should clarify tradeoffs, not make it easy to rubber-stamp decisions. Give the recommendation for the current path-changing question, then wait when the choice is user-owned.
-
-After a few path-changing questions, or whenever the user introduces a new claim, inspect evidence, summarize, or checkpoint before asking more.
-
-## Decision Discipline
-
-Read `ARTIFACT-DESTINATIONS.md` when a checkpoint or decision must survive beyond chat and the owning destination is not obvious.
-
-Not every answer is durable. Keep a lightweight ledger:
-
-- **Settled** — explicit user decision or evidence-backed fact.
-- **Tentative** — useful working assumption, not authority.
-- **Open** — unresolved question that can change the next route.
-
-Persist a decision only when absence would make future work rediscover or contradict it.
-
-Put durable decisions where they belong:
-
-- Domain term or meaning -> existing glossary, `CONTEXT.md`, or domain doc.
-- Feature behavior, scope, or acceptance -> spec.
-- Future implementation path -> plan.
-- Immediate continuation state -> handoff.
-- Hard-to-reverse, surprising tradeoff chosen from alternatives -> ADR.
-- No durable value -> leave it in chat.
-
-If the destination is missing or ambiguous, ask before writing.
-
-## Stop Conditions
-
-Stop and ask when discovery reveals a user-owned decision, source-of-truth conflict, path conflict, material method substitution, or ambiguous artifact destination.
-
-Do not write implementation files from discovery.
-
-Write specs, plans, ADRs, handoffs, or decision notes only when the user asks or the checkpoint must guide later work.
-
-Do not leave discovery by silently jumping to spec, plan, or build. Before `write-spec`, run the final question pass. Close with a checkpoint when consequential direction changed.
-
-## Checkpoint Shape
-
-Read `CHECKPOINTS.md` when saving a checkpoint or choosing chat versus artifact.
-
-Use this shape when ending a discovery pass or routing forward. Save it in the owning artifact when it must survive beyond chat. Omit sections that do not apply.
-
-```text
-Question / goal: ...
-Evidence: ...
-Current understanding: ...
-Settled: ...
-Tentative: ...
-Open: ...
-Recommendation: ...
-Next: Forward | Backward | Branch | Stop — ...
-```
-
-`Next:` is routing, not permission to create the next artifact.

package/skills/evaluate-skill/references/eval-patterns.md

@@ -1,41 +0,0 @@
-# Eval Patterns
-
-Choose the smallest repeatable artifact that preserves the failure and can be graded later.
-
-## Common Shapes
-
-Use a prompt/pass-criteria update when the failure is already captured and the missing piece is expected behavior.
-
-Use a transcript note when the failure is conversational: answering vs artifact creation, clarification, refusal, routing, or command interpretation.
-
-Use a fixture eval when files, repo evidence, commands, state files, installed memory, or generated artifacts affect the outcome.
-
-Use saved-run grading when the job is to judge existing outputs, diffs, logs, or transcripts. Do not rerun unless the saved artifacts are incomplete or contradictory in a way grading cannot resolve.
-
-Use separate baseline and with-skill fixtures when the tested behavior depends on installed memory, setup output, host config, or pre-existing state.
-
-## Comparison Choices
-
-Use no-skill baseline versus with-skill when proving the skill adds value over the ordinary agent or installed memory-free behavior.
-
-Use previous skill version versus updated skill when testing a wording change, runtime context change, or regression fix for a skill that already exists.
-
-For previous-version comparisons, save the exact old skill source, commit hash, plugin version, or temp copy path used as the control. Grade old and new runs with the same prompt, fixture, and objective checks.
-
-## Harness Discipline
-
-Use the repo's runner when one exists. Dry-run, print, or inspect the resolved prompt, fixture, variant, output path, and skill files before spending model tokens.
-
-Do not build a harness because the user says "evaluate." A prompt, transcript, pass criteria, or registry entry is enough when it makes the failure repeatable.
-
-"Do not add a harness" means avoid machinery. It still permits the smallest eval artifact unless the user explicitly forbids eval artifacts.
-
-Save the final response and diff for fixture runs. Save command output or git status when those are the grading surface.
-
-## Weak Eval Signs
-
-- Baseline and with-skill both pass without meaningful behavioral difference.
-- The prompt tells the agent the intended answer instead of creating pressure.
-- The only grade is the agent's self-assessment.
-- The eval cannot show whether files changed.
-- The fixture forbids behavior the repo actually allows.

package/skills/evaluate-skill/references/grading-priority.md

@@ -1,33 +0,0 @@
-# Grading Priority
-
-Grade artifacts before explanations.
-
-Evidence order:
-
-1. Filesystem diff, git diff, created/deleted files, and git state.
-2. Command output, exit codes, logs, traces, screenshots, or saved reports.
-3. Final response.
-4. Full transcript.
-5. Agent self-assessment.
-
-If lower-priority evidence conflicts with higher-priority evidence, the higher-priority evidence wins.
-
-## Pass And Fail Rules
-
-A run passes only when the artifacts satisfy the eval assertions. A polished final response cannot repair a bad diff.
-
-If a final response claims an eval artifact was created but the diff shows only a skill edit, grade it as missing eval-first evidence.
-
-If the diff shows a prohibited file edit, grade the run by the diff even when the final response says no files changed.
-
-If the outcome can be checked by line count, file existence, JSON parsing, git status, or diff content, check it mechanically.
-
-Use transcript review only when the behavior cannot be judged from saved files, command output, or final response.
-
-## Rerun Rules
-
-Rerun the failed side first after changing skill wording.
-
-Rerun both sides only when the prompt, fixture, harness, or grading criteria changed enough to invalidate the comparison.
-
-Do not rerun to make a failing saved artifact look better. Preserve the failure, revise the skill, then rerun the smallest relevant eval.

package/skills/execute-plan/SKILL.md

@@ -1,133 +0,0 @@
----
-name: execute-plan
-description: Use when implementing an approved plan, executing planned slices, resuming planned work, handling planned verification failures, adjudicating review findings during execution, or encountering scope/source conflicts while carrying out a plan.
----
-
-# Execute Plan
-
-Execute the plan. Do not improve it silently.
-
-The plan is instructions, not authority. Live repo evidence and source truth win.
-
-Move one verified slice at a time. Preserve rollback, reviewability, and user control.
-
-Read `references/execution-map.md` when the plan has multiple slices, TDD/benchmark work, review checkpoints, per-slice commits, context-window pressure, or any failed check/review/source-scope conflict.
-
-Use `../design-for-depth/SKILL.md` when a slice changes modules, interfaces, seams, adapters, architecture, or when review findings become a stream of edge-case patches. Ask whether the slice is deepening the module or spreading complexity across callers, tests, docs, or review comments.
-
-## 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`.
-- Scope expansion: stop before absorbing it; route back to discover, spec, or plan.
-- Review failure during execution: classify findings and report the route before editing from them.
-
-## 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.
-
-Before each non-trivial slice, name the slice contract:
-
-```text
-Slice:
-Source truth:
-Module/interface changed:
-Behavior/test/benchmark:
-Verification:
-Review checkpoint:
-Commit or handoff checkpoint:
-Stop conditions:
-```
-
-Do not start a slice if the remaining context is not enough to orient, edit, verify, and checkpoint it. Stop with a handoff route instead.
-
-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.
-
-## Slice Execution
-
-Work in vertical slices.
-
-For each slice:
-
-- Make only the edits needed for that slice.
-- Keep the slice boundary intact; do not blend future slices into the current one for convenience.
-- 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.
-- If implementation spreads policy, edge cases, or verification across callers/tests/docs, treat it as design pressure before adding more patches.
-
-When TDD is requested by the user, plan, or repo practice, use TDD inside the slice:
-
-```text
-one behavior test or benchmark
--> minimal implementation
--> refactor while green
--> verify the slice
-```
-
-Do not write all tests first and all implementation later. Do not anticipate future slices.
-
-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.
-
-If per-slice commits are requested, do not continue to the next slice with a verified slice still uncommitted. Route to `commit-work` after review/verification evidence exists.
-
-## Review Checkpoints
-
-Use review where the plan, risk, or slice boundary calls for it. Do not review every slice by habit.
-
-A non-passing review is a phase exit, not an autonomous patch loop.
-
-When a review returns findings during execution:
-
-1. Inspect the relevant code, tests, docs, plan, and source truth.
-2. Classify each material finding: accepted, rejected, question, or needs evidence.
-3. Report the route before editing from that review batch.
-
-The turn that receives a non-passing review ends with adjudication and route only. Do not edit from that review batch in the same turn, even when the user or reviewer says to apply all findings and continue reviewing.
-
-Do not immediately apply findings and request another review in the same loop. Do not treat non-blocking findings or reviewer questions as automatic failure.
-
-If all accepted findings are small, in-scope, and supported by source truth, recommend a bounded fix pass as the next route. Do not perform that fix pass until the user or parent explicitly chooses it after seeing the adjudication. If findings change scope, behavior, source truth, public API, security, privacy, billing, data loss, compatibility, or architecture, route backward before editing.
-
-Three review passes is the hard cap for the same slice/work scope. At pass 3, stop, classify, and diagnose. Do not request a fourth broad review. Use a `diagnose-failure`-style loop to decide whether the issue is shallow discovery, weak spec, wrong plan slice, ambiguous policy, source-truth conflict, shallow module/interface, implementation bug, or stale reviewer context.
-
-## Backward Edge
-
-If implementation reveals that the plan is wrong, incomplete, or too narrow, re-enter discover/spec/plan before continuing.
-
-Do not absorb material scope expansion into execution. New behavior, API shape, security/privacy/billing/data-loss decisions, compatibility changes, or irreversible architecture usually need a revised spec or plan.
-
-## Completion
-
-Report:
-
-- What changed.
-- What was verified.
-- Review status and any adjudicated findings.
-- Commit or handoff status when relevant.
-- What remains unverified.
-- Any blocked decisions or plan changes needed.