@hassangameryt/freeflow 0.2.0 → 0.4.0

package/plugins/freeflow/skills/verify-work/SKILL.md

@@ -1,62 +0,0 @@
----
-name: verify-work
-description: Use before claiming work is done, fixed, passing, implemented, reviewed, or ready; when verification fails; or when the user asks to skip checks but still wants a completion claim.
----
-
-# Verify Work
-
-Do not claim completion without fresh evidence.
-
-## Evidence Rule
-
-Before saying work is done, fixed, passing, implemented, reviewed, or ready, verify the claim.
-
-Good evidence can be:
-
-- Passing tests.
-- Typecheck, lint, build, or formatter output.
-- Reproducing a bug before and after a fix.
-- Inspecting the changed file when no executable check exists.
-- A targeted manual check.
-
-Use the smallest verification that proves the claim.
-
-## Claim Rule
-
-Match the claim to the evidence.
-
-- If tests passed, say which tests passed.
-- If only a file was inspected, say that.
-- If no runnable check exists, say the work is unverified by automation.
-- If the user asks to skip checks, skip the checks but do not claim verified or passing.
-
-Never convert "I changed the code" into "it works" without evidence.
-
-## Failure Rule
-
-If verification fails, stop and report the evidence.
-
-Do not patch randomly. Decide whether the failure means:
-
-- Implementation bug.
-- Bad or stale test.
-- Source-of-truth conflict.
-- Missing environment/dependency.
-- User-owned product/domain decision.
-
-If the failure challenges the spec, plan, docs, policy, or tests, re-enter the interview gate before changing direction.
-
-## Final Response
-
-Use this shape:
-
-```text
-Changed: ...
-Verified: ...
-Not verified: ...
-Next: ...
-```
-
-For completed consequential work, `Next:` is mandatory. Omit it only for direct question answers, mid-task status, or clarification-only turns.
-
-Keep it short.

package/plugins/freeflow/skills/workflow/SKILL.md

@@ -1,95 +0,0 @@
----
-name: workflow
-description: Use when doing consequential work such as implementation, bug fixing, planning, research-for-action, review, verification, or handoff.
----
-
-# Workflow
-
-Follow a lightweight forward workflow. Scale process to task risk.
-
-Move forward when context is sufficient. Re-enter clarification when new ambiguity would change the next action.
-
-Question means answer. Do not turn a question into a file edit, report, plan, or implementation.
-
-```text
-Clarify / Research
--> Decision / Spec
--> Plan
--> Execute
--> Review
--> Verify
--> Handoff
-```
-
-This is a guide, not ceremony. Small reversible work can skip spec/plan artifacts.
-
-Method skills such as TDD, diagnosis, or execute-plan run inside the current workflow phase. Workflow owns routing, source-truth conflicts, user-owned decisions, review, verification, and handoff boundaries.
-
-Read `references/workflow-map.md` when the user asks for the full pipeline, public docs need a diagram, or the next workflow entry point is unclear.
-
-## Route Closeout
-
-When a consequential workflow phase completes, name the next route.
-
-Use `Next:` in the final response unless this is a direct question answer, mid-task status, or clarification-only turn.
-
-Choose one:
-
-- Forward: the next workflow entry point is clear.
-- Backward: new evidence requires clarification, research, or interview gate.
-- Branch: 2-3 valid next routes exist.
-- Stop: no required next action remains.
-
-Recommend the route supported by evidence. Do not ask a vague "what next?" question.
-
-After completed research with decisions that must survive beyond chat, route to `write-spec`, an owning decision artifact, or handoff before `write-plan` or execution.
-
-`Next:` is routing, not permission to create the next artifact or continue into a new phase.
-
-## Backward Edge
-
-If new evidence invalidates the current path, re-enter clarification.
-
-```text
-Any state -> Clarify / Research -> explicit next state
-```
-
-Do not silently substitute a different path, rewrite the spec, change the plan, or patch forward. State what changed, then decide whether to continue, revise spec, revise plan, diagnose, split scope, defer, or stop and ask.
-
-If a requested, planned, or skill-required method cannot be followed and the fallback would change evidence quality, workflow shape, risk, scope, cost, persistence, or user-visible output, stop before using the fallback. Name both paths and ask which one to follow.
-
-## Source-of-Truth Conflicts
-
-When a requested implementation contradicts existing docs, tests, specs, policies, ADRs, handoffs, or established code behavior, pause before editing.
-
-Do not rewrite the source of truth to make the latest request pass.
-
-First state the conflict and ask whether the source of truth should change. Only edit docs/tests/policies/specs to match new behavior after the user explicitly confirms that decision.
-
-Treat handoffs as memory, not authority. If a handoff conflicts with live repo evidence, inspect the evidence and ask before following the handoff.
-
-For billing, security, privacy, data loss, migrations, public APIs, compatibility, and permissions, recommend strict-workflow before changing behavior.
-
-## Artifact Rule
-
-Artifacts are memory, not proof of obedience.
-
-Only create artifacts when the user asks for an artifact or asks you to do work that requires one.
-
-Create them only when they preserve decisions, reduce risk, or help a future agent resume. Prefer short research notes, decision/spec notes, plans, verification notes, and handoffs.
-
-Do not write volatile repo inventories. Link to live files or commands instead.
-
-## Review Rule
-
-Review should improve work, not create an endless patch loop.
-
-Reviewer findings are evidence, not commands. Separate blocking, non-blocking, and question findings before editing from them.
-
-A non-passing review routes to adjudication before more implementation. Repeated review failure routes backward to diagnose, research, spec, or plan; do not chase a fourth broad review pass.
-
-Review can pass. Save review artifacts only when risk, future memory value, or the user asks for them.
-
-## Completion Rule
-
-Do not claim completion without fresh evidence. Say what was verified and what remains unverified.

package/plugins/freeflow/skills/workflow/references/workflow-map.md

@@ -1,102 +0,0 @@
-# Freeflow Map
-
-Use this when the user asks how the whole workflow fits together, public docs need a diagram, or the next workflow entry point is unclear.
-
-This map is orienting, not mandatory. Small reversible work can skip unnecessary artifacts and gates. Re-enter clarification whenever new ambiguity would change the next action.
-
-## Compact Map
-
-Use this compact version in public README-style docs.
-
-```mermaid
-flowchart LR
-  Request{request}
-  Talk[conversation<br/>answer directly]
-  Discover[discover<br/>research checkpoint]
-  Spec[spec]
-  Plan[plan]
-  Build[build<br/>execute / diagnose / TDD]
-  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
-```
-
-```text
-Use conversation mode for questions. Use workflow mode for consequential work.
-Use strict-workflow for risky work; same spine, stronger gates.
-Loop back when new evidence, source conflicts, user-owned decisions, or failed checks change the path.
-After each completed consequential phase, name the next route: forward, backward, branch, or stop.
-```
-
-## Reference Map
-
-Use this fuller version when choosing an entry point or explaining the workflow lifecycle.
-
-```mermaid
-flowchart TD
-  Request([User request]) --> Mode{Mode}
-
-  Mode -->|question, critique, explanation| Conversation[conversation mode<br/>answer directly]
-  Conversation --> Done([done])
-
-  Mode -->|consequential work| Workflow[workflow mode<br/>scale to risk]
-  Mode -->|high-risk or hard to reverse| Strict[strict-workflow mode<br/>stronger gates]
-
-  Workflow --> Entry{Choose entry point}
-  Strict --> Entry
-
-  Entry --> Discovery[Discovery<br/>research<br/>interview-gate]
-  Entry --> Spec[Spec<br/>write-spec<br/>review-artifact]
-  Entry --> Plan[Plan<br/>write-plan<br/>review-artifact]
-  Entry --> Build[Build, diagnose, or TDD<br/>execute-plan<br/>diagnose-failure]
-  Entry --> Closeout[Closeout<br/>review-work<br/>verify-work<br/>commit-work]
-
-  Discovery --> Spec
-  Spec --> Plan
-  Plan --> Build
-  Build --> Closeout
-  Closeout --> Handoff[handoff<br/>durable checkpoint when needed]
-  Handoff --> Done
-
-  Reenter[Re-enter discovery<br/>new evidence, owner decision,<br/>source conflict, or failed check]
-  Spec -.-> Reenter
-  Plan -.-> Reenter
-  Build -.-> Reenter
-  Closeout -.-> Reenter
-  Handoff -.-> Reenter
-  Reenter --> Discovery
-
-  Bypass[bypass<br/>skip ceremony, not judgment] -.-> Entry
-```
-
-## Common Entry Points
-
-- Use `conversation mode` when the user asks a question, wants critique, or is exploring.
-- Use `research` when repo, domain, evidence, current facts, brainstorming, targeted questions, or a decision checkpoint are needed before spec, plan, build, or durable memory.
-- Use `interview-gate` when direction is vague, source truth conflicts, or user-owned decisions are still open.
-- Use `write-spec` when requirements are agreed but not durable.
-- Use `review-artifact` when a spec, plan, handoff, or decision note must guide future work.
-- Use `write-plan` when an approved spec or explicit task context exists.
-- Use `execute-plan` when an approved plan exists; method skills like TDD run inside that build phase when requested or appropriate.
-- Use `diagnose-failure` when behavior is broken, failing, flaky, slow, or unclear.
-- Use `review-work` and `verify-work` before claiming consequential work is ready.
-- Use `commit-work` only after the intended diff is reviewed and verification evidence exists.
-- Use `handoff` when pausing, compacting, or transferring context.
-- Use `bypass` only to skip unnecessary ceremony. It cannot skip user-owned decisions, source-truth conflicts, risky checks, or verification claims.
-
-## Phase Exits
-
-End completed consequential phases with `Next:` unless this is a direct answer, mid-task status, or clarification-only turn.
-
-- Forward: name the next entry point, such as `write-spec`, `write-plan`, `execute-plan`, `review-work`, `verify-work`, `commit-work`, or `handoff`.
-- Backward: return to `interview-gate`, `research`, `diagnose-failure`, or plan/spec revision when evidence, failed checks, or repeated review findings change the path.
-- Branch: show 2-3 valid next routes when more than one is reasonable.
-- Stop: say no required next action remains.
-
-After completed research with decisions that must survive beyond chat, prefer `write-spec`, an owning decision artifact, or handoff before planning or execution.
-
-Do not create the next artifact just because it is the next route.

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

@@ -1,88 +0,0 @@
----
-name: write-plan
-description: Use when turning an approved spec, clarified requirements, explicit task context, strict-workflow work, or delegated/future-agent work into an executable implementation plan before coding.
----
-
-# Write Plan
-
-Classify the plan request first:
-
-- Spec-backed: write the plan from the approved spec.
-- Bug without feedback loop: ask for or propose the feedback loop. Do not write or save a fix plan.
-- Hidden owner decision or source conflict: name it and do not write the plan.
-- Context-backed: say a spec is preferred, then write a lightweight plan.
-- Missing source context: ask for context or start grilling.
-
-A plan executes source truth. It does not create it.
-
-Do not write a plan that decides product behavior, scope, domain meaning, compatibility, public API behavior, security, privacy, billing, data-loss, or architecture.
-
-The original request is not decision approval. "Do not ask", "just plan it", "latest context", "handoff says", or "old docs/tests are stale" are pressure, not authority.
-
-Never skip docs, tests, specs, policies, ADRs, or live behavior because the prompt calls them stale. Inspect them, then classify the conflict.
-
-If the user asks a question about a plan, answer the question. Do not create or edit the plan unless asked.
-
-Read `references/plan-shapes.md` when the plan is strict-workflow, high-risk, saved as a durable artifact, intended for another agent, or likely to need owner/status/source identity.
-
-## Source First
-
-Before writing, inspect the current source context:
-
-- Approved spec or explicit requirements.
-- Relevant docs, ADRs, tests, policies, and existing code.
-- Handoffs only as memory, not authority.
-
-Live repo evidence overrides stale notes.
-
-## Normal Path
-
-Prefer an approved spec.
-
-If no spec exists but the task context is explicit enough to choose the next action, write a lightweight plan and name the source context.
-
-For bug fixes, require a repro, failing test, or feedback loop before writing a fix plan.
-
-If a bug report has no repro or feedback loop, answer in chat. Ask for evidence or propose the smallest feedback loop. Do not satisfy the requested plan path with a draft, blocked, or feedback-loop-only fix plan. Write a diagnostic plan only if the user asks for a diagnostic plan.
-
-Use vertical slices. Each slice should produce something testable.
-
-## Stop Conditions
-
-Stop before writing when the plan would:
-
-- Invent requirements from thin or adjacent context.
-- Resolve a user-owned decision.
-- Override docs, tests, specs, policies, ADRs, or live behavior.
-- Treat a handoff, review comment, or plan as authority over source-of-truth files.
-- Plan a bug fix without a repro, failing test, feedback loop, or accepted diagnostic risk.
-- Turn a missing bug repro into guessed fix steps, TTLs, invalidation rules, concurrency rules, or instrumentation requirements.
-- Hide uncertainty inside implementation steps.
-
-Name the missing decision or conflict. Ask which path to follow. Recommend the path supported by evidence.
-
-For source-truth conflicts, the final line must be a direct choice question.
-
-## Shape
-
-Adapt the plan to risk. Prefer:
-
-- Durable plan identity when the plan is saved for future agents or teammates.
-- Goal.
-- Source spec or context.
-- Files likely touched.
-- Vertical slices.
-- Tests or checks per slice.
-- Commands where known.
-- Stop conditions.
-- Review or verification checkpoints.
-
-Keep it concise. Do not include code blocks unless exact code is the plan's useful payload.
-
-## Completion
-
-After writing, report:
-
-- The artifact path, if saved.
-- The source context used.
-- Any decisions still blocked.

package/plugins/freeflow/skills/write-plan/references/plan-shapes.md

@@ -1,70 +0,0 @@
-# Plan Shapes
-
-Use this for strict-workflow, high-risk, durable, or delegated plans.
-
-## Durable Plan Identity
-
-When saving a plan that future agents or teammates will rely on, start with a compact header:
-
-```md
-> **Doc ID:** PLAN-001-billing-webhook-api
-> **Date:** 2026-05-26
-> **Owner:** Hassan Mohiddin
-> **Type:** Plan
-> **Status:** Ready
-> **Source:** docs/specs/billing-webhook-api.md
-```
-
-Rules:
-
-- `Doc ID`: stable and readable. Prefer `PLAN-###-slug` when no repo convention exists.
-- `Owner`: use the spec/product owner when known. In normal workflow, use `User` only when the requester is the only known owner.
-- `Status`: use `Draft` when decisions/checks are still incomplete; use `Ready` when the plan is executable.
-- `Source`: cite the approved spec, clarified context, issue, ADR, or docs used as authority.
-
-In strict-workflow for security, billing, privacy, public API, migration, data-loss, or architecture work, stop and ask if owner/status/source would be guessed.
-
-Do not add a changelog on first creation.
-
-## Lightweight Plans
-
-Use for low-risk context-backed work:
-
-- goal
-- source context
-- files likely touched
-- short slices
-- checks
-
-Mention that a spec is preferred when no approved spec exists, but do not add artifact pressure for tiny reversible work.
-
-## Normal Plans
-
-Use for spec-backed feature work:
-
-- goal
-- source context
-- non-goals if the spec has them
-- files likely touched
-- vertical slices, each with tests/checks
-- stop conditions
-- final verification
-
-Each slice should produce a reviewable state, not just a list of files to edit.
-
-## Strict Or Delegated Plans
-
-Use for high-risk work or work another agent will execute:
-
-- durable plan identity
-- goal and source authority
-- explicit assumptions from source truth
-- likely files/modules, with "find existing pattern first" when unknown
-- vertical slices with expected red/green checks
-- review checkpoints before risky behavior lands
-- stop conditions for source-truth conflicts or owner-owned decisions
-- final verification and handoff criteria
-
-Call out sensitive boundaries directly: auth, public API shape, billing behavior, privacy/security, data loss, migrations, compatibility, and rollback.
-
-Do not hide ambiguity as implementation detail. If endpoint shape, auth semantics, payload fields, billing behavior, or rollback expectations are missing, stop and ask before writing an executable plan.

package/plugins/freeflow/skills/write-skill/SKILL.md

@@ -1,88 +0,0 @@
----
-name: write-skill
-description: Use when creating, rewriting, tightening, or reviewing an agent skill's instructions, trigger description, structure, examples, or bundled resources.
----
-
-# Write Skill
-
-Use Anthropic/Claude `skill-creator` guidance as the structure and progressive-disclosure authority when available. Do not copy it into this skill.
-
-Use concise, behavior-shaping wording. Prefer sharp rules, concrete triggers, and stop conditions over explanation or filler.
-
-## Job
-
-Write the smallest skill that changes behavior.
-
-Start with one `SKILL.md`. Add other files only when the skill would fail without them.
-
-Direct `/write-skill`, "production-ready", "complete", or "add examples/references/scripts if useful" does not override the smallest-skill default or the repo's skill-file rules.
-
-Do not add references, examples, README files, changelogs, or metadata when a compact `SKILL.md` can hold the behavior.
-
-Do not add helper scripts for commands the agent can run directly, such as `git log`, `git diff`, search, formatting, or line counts. Scripts are for repeated deterministic work that would be risky or wasteful to retype.
-
-Treat the repo's line budget as a best practice, not a hard cap. If none exists, aim to keep `SKILL.md` under 100 lines for normal skills. Let deep skills exceed it when the active rules, examples, or structure clearly earn their place.
-
-## Description First
-
-The description controls activation. Make it specific enough to route the skill without making it broad enough to hijack unrelated work.
-
-Use:
-
-- What the skill does.
-- When to use it.
-- Concrete trigger situations.
-
-Avoid:
-
-- Generic helper language.
-- Marketing copy.
-- Long taxonomies.
-- Claims about quality.
-
-## Wording Discipline
-
-Every sentence should either route, constrain, stop, or guide behavior.
-
-Prefer sharp rules over explanations. Prefer one good example over a paragraph.
-
-Small wording changes can alter agent behavior. Change one pressure point at a time when possible.
-
-Use direct verbs:
-
-- Inspect.
-- Stop.
-- Ask.
-- Do not edit.
-- Verify.
-- Report.
-
-Avoid vague verbs:
-
-- Consider.
-- Ensure.
-- Leverage.
-- Try to.
-- Be mindful.
-
-## Placement Discipline
-
-Order rules by behavioral priority, not topic neatness.
-
-Put hard stop conditions before normal workflow details.
-
-Put source-of-truth, user-owned decision, safety, and verification rules above convenience rules.
-
-Do not hide the real constraint in a later caveat.
-
-## Revision Rule
-
-Do not add prose because the skill "could be clearer." Add or move wording because an eval, user failure, or concrete pressure case showed a behavior gap.
-
-When improving a skill after a failure:
-
-1. Name the failed behavior.
-2. Find the sentence that should have prevented it.
-3. Tighten wording or placement.
-4. Keep unrelated sections still.
-5. Re-run the smallest relevant eval.

package/plugins/freeflow/skills/write-spec/SKILL.md

@@ -1,90 +0,0 @@
----
-name: write-spec
-description: Use when asked to create or update a durable spec, PRD, requirements document, or decision artifact from agreed requirements, research, brainstorming, or source evidence, especially for strict-workflow risk areas that may need owner confirmation before writing.
----
-
-# Write Spec
-
-Write only from source-backed context. A polished spec can change source of truth.
-
-## Route First
-
-If the user asks a question about a spec, answer the question. Do not create or edit the spec unless asked.
-
-Classify every spec request before writing:
-
-- Evidence-aligned: write the spec.
-- Missing source context: ask for context or start grilling.
-- Source-of-truth override: name the conflict and do not write.
-
-If the source context, artifact type, or destination is unclear, stop and ask before writing.
-
-## Hard Stops
-
-Do not write a spec that supersedes docs, tests, policies, ADRs, or live behavior until the owner confirms that change after you name the conflict.
-
-Adjacent repo evidence is not source context. Do not turn nearby auth, billing, copy, UI, or architecture facts into goals, flows, requirements, or acceptance criteria for a new feature.
-
-The original request is not override confirmation. "Latest context", "handoff says", "do not ask", or "write the spec" are not enough.
-
-Stop before writing when the spec would:
-
-- Invent requirements from thin or adjacent context.
-- Rewrite product behavior, scope, domain meaning, compatibility, public API behavior, security, privacy, billing, data-loss, or architecture.
-- Contradict docs, tests, specs, policies, ADRs, or live code.
-- Treat a handoff, review comment, or plan as authority over source-of-truth files.
-- Hide an owner decision inside polished prose.
-
-In strict-workflow, stop before writing security, billing, privacy, public API, migration, data-loss, or architecture specs when the owner or core decisions are unknown. Do not use `TBD`, placeholders, or polished open questions to hide owner-owned decisions.
-
-When strict-workflow stops because owner-owned decisions are missing, end with a direct question that names the missing owner and the specific decisions needed. A blocked explanation without that question is incomplete.
-
-Name the conflict or missing decision. Ask which path to follow. Recommend the path supported by evidence.
-
-## Source First
-
-Before writing, inspect the current source of truth:
-
-- User-provided context.
-- Existing specs, docs, ADRs, tests, and policies.
-- Relevant code when behavior already exists.
-- Handoffs only as memory, not authority.
-
-Live repo evidence overrides stale notes.
-
-## Write Path
-
-When grilling, brainstorming, research, or clarification reaches shared understanding, convert that agreed context into a spec. Do not re-interview from scratch.
-
-If remaining ambiguity would not change the next plan, write the spec and mark the ambiguity as open.
-
-Use this shape unless the repo has a stronger convention:
-
-- Problem.
-- Intended outcome.
-- Scope / out of scope.
-- Requirements.
-- Acceptance criteria.
-- Decisions made.
-- Constraints / evidence.
-- Open questions.
-
-Read `references/spec-shapes.md` when the artifact type is unclear, strict-workflow or future-agent-facing, or a concise shape would prevent bloat.
-
-Keep it concise. Do not include volatile repo inventory. Use file paths only when they are needed evidence.
-
-## Durable Artifact Details
-
-For durable specs or future-agent-facing artifacts, follow `references/artifact-standards.md`.
-
-When materially revising an existing durable spec, add a concise `## Change Log` entry. Do not add a changelog on first creation.
-
-Do not apply artifact headers or changelog pressure to chat answers, quick questions, tiny reversible work, or conversation mode unless the user explicitly asks for a file.
-
-## Completion
-
-After writing, report:
-
-- The artifact path.
-- The source context used.
-- Any open questions or decisions still blocked.

package/plugins/freeflow/skills/write-spec/references/artifact-standards.md

@@ -1,67 +0,0 @@
-# Artifact Standards
-
-Use this only for durable artifacts: specs, PRDs, decision artifacts, requirements docs, living docs, policies, or docs future agents or teammates will rely on.
-
-Do not apply this to chat answers, quick questions, tiny reversible work, or conversation mode unless the user explicitly asks for a file.
-
-## Header
-
-For durable specs, start with a compact header:
-
-```md
-> **Doc ID:** SPEC-001-team-invitations
-> **Date:** 2026-05-26
-> **Owner:** Hassan Mohiddin
-> **Type:** Spec
-> **Status:** Draft
-> **Source:** User-provided decision session
-```
-
-Rules:
-
-- `Doc ID`: stable, readable, and unique enough for the repo. Prefer `SPEC-###-slug` when no convention exists.
-- `Date`: creation date.
-- `Owner`: use the named product/technical owner when known. In normal workflow, use `User` if the requester is the only known owner. In strict-workflow, ask when owner is unknown.
-- `Type`: `Spec`, `PRD`, `Decision`, or the artifact type requested.
-- `Status`: usually `Draft` for new specs unless the user or repo says otherwise.
-- `Source`: name the evidence used, not a transcript. Examples: `Shared grilling context`, `docs/research/team-invitations.md`, `User-provided decision session`.
-
-Optional team fields:
-
-```md
-> **Approver:** Platform Lead
-> **Reviewers:** Security, Billing
-> **Last Updated:** 2026-05-27
-```
-
-Add optional fields only when the user, repo, team setting, or strict-workflow risk makes them useful.
-
-## Mode Pressure
-
-- Conversation mode: no artifact or header pressure. Answer questions directly.
-- Workflow mode: use the header for durable specs and future-agent-facing artifacts.
-- Strict-workflow mode: require explicit owner and status for security, billing, privacy, public API, migration, data-loss, and architecture work. Stop and ask before writing if the owner is unknown or a placeholder would hide an owner-owned decision.
-
-## Statuses
-
-Use small status sets:
-
-| Artifact | Statuses |
-| --- | --- |
-| Spec / PRD / Design Brief | `Draft`, `Approved`, `Implemented`, `Rejected` |
-| Plan | `Draft`, `Ready`, `Executed`, `Abandoned` |
-| Decision / ADR | `Proposed`, `Accepted`, `Rejected`, `Superseded` |
-| Bug / Diagnosis | `Investigating`, `Fixed`, `Verified`, `Rejected` |
-| Runbook / Living Doc / Policy | `Current`, `Outdated`, `Deprecated` |
-
-Do not invent a large workflow taxonomy.
-
-## Change Log
-
-Do not add a changelog on first creation.
-
-Add `## Change Log` after a material revision, status transition, or implementation divergence.
-
-Use changelogs for living docs, runbooks, policies, and long-lived architecture docs.
-
-Never use a changelog as a transcript. Record meaningful document evolution only.