sungyongcho · Sep 8, 2026 · Sep 7, 2026 · Sep 7, 2026 · Sep 7, 2026 · Sep 8, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -2,6 +2,16 @@
 
 ## Unreleased
 
+## 4.0.0 - 2026-09-07
+
+- Make concise canonical Markdown fields/nested lists the public OPS record format;
+  reject legacy JSON in normal reads and prohibit fenced or hidden duplicate payloads.
+- Require an explicitly authorized audited migration of OPS-generated records in place,
+  preserving IDs, authors and semantic evidence while excluding human content and Git history.
+- Let a requested separate reviewer repair clear implementation-scope defects directly
+  on the same PR, record reviewer-as-contributor and verify the final head before readiness.
+- Preserve paused-writer, declared-scope, personal commit/push and no-automatic-merge boundaries;
+  reviewer corrections are disclosed rather than represented as independently reviewed.
 - End ordinary worker delivery at REVIEW_READY; require an implementing-worker review
   request and a different task, with ordinary self-review only by explicit user approval.
 - Add MERGE_READY alongside REVIEW_READY after eligible review and current head/base/checks;

diff --git a/README.md b/README.md
@@ -114,22 +114,30 @@ Read [worker coordination](references/worker-coordination.md) for named workers
 [PR review](references/pr-review.md) for review work. Reload the real source when another
 conversation may have updated it; existing context is not rewritten by filesystem changes.
 
-### Worker succession in 3.0.0
+### Readable records and review repair in 4.0.0
 
 Workers are replaceable execution owners. Project assignments, commits, PRs and tested
 checkpoints preserve continuity when chats disappear or a later model takes over.
 Explicit user approval transfers named work without waiting for a predecessor response;
-existing IDs and v1 records remain valid. The changed transfer contract is the reason
-for the major version, not an incompatible storage migration.
+existing IDs and canonical Markdown record identities remain valid. Version 4 changes
+the public record format and reviewer repair contract: normal OPS record reads no longer
+fall back to legacy JSON. An explicitly authorized audited migration updates existing
+OPS-generated records in place, excluding human/unmanaged content and Git history.
 
 The coordination reference defines collision-checked IDs, assignment lineage, OPS
 ownership/commit receipts, and `DEV`/`OPS` plus `OCCUPIED`/`REVIEW_READY` label synchronization.
 Ordinary implementation ends at `REVIEW_READY`. Code review requires the implementing
 worker's request and a different task; ordinary self-review needs explicit user approval.
-A valid review and current head/base/checks add `MERGE_READY` alongside `REVIEW_READY`.
+The separate reviewer directly fixes clear in-scope defects on the same PR, pauses the
+original writer, and records its contribution. It does not claim independent review of
+its own corrections. A valid review of the final head plus current checks adds
+`MERGE_READY` alongside `REVIEW_READY`.
 Neither label grants merge rights; new edits or invalidated evidence remove `MERGE_READY`.
-Personal accounts still author development commits and create PRs when the repository
-separates those actions from OPS records. Labels do not grant ownership or merge authority.
+Public records use concise headings and one authoritative set of Markdown fields and
+nested lists, strictly parsed by tools. No JSON fences or hidden metadata duplicates are
+published. Human-readable summaries link detailed evidence instead of dumping payloads.
+Personal accounts still author development and reviewer repair commits and create PRs
+when the repository separates those actions from OPS records. Labels do not grant ownership or merge authority.
 
 Conversation names follow `<short scope> | <project summary> | <short worker id>`.
 Use supported official tools and verify the new title; otherwise provide the suggested
@@ -144,8 +152,9 @@ This repository is the canonical reusable package. Keep private routing, host po
 credentials and machine-specific settings outside it. Use one local source with links
 for authoring and reviewed commit pins for distributed recovery snapshots.
 
-Ordinary policy edits do not bump the release version. Track working changes by content
-hash and Git state. Resolve pending related changes before selecting a release number.
+With user authorization for autonomous version maintenance, select a patch, minor or
+major bump when verified changes warrant it. Do not bump per conversation. Track working
+changes by content hash and Git state; reconcile related changes and consumer pins.
 See [release policy](docs/releasing.md) and [unreleased changes](CHANGELOG.md).
 
 ```sh

diff --git a/SKILL.md b/SKILL.md
@@ -1,8 +1,8 @@
 ---
 name: commit-it
-description: Track requested features, fixes and GitHub delivery, prepare authorized issue-linked commits, perform scoped PR reviews, and resolve an explicitly assigned PR set through verified integration and authorized ordered merges.
+description: Track requested features, fixes and GitHub delivery, prepare authorized issue-linked commits, perform requested PR reviews and bounded repairs, and resolve an explicitly assigned PR set through verified integration and authorized ordered merges.
 metadata:
-  version: "3.0.0"
+  version: "4.0.0"
 ---
 
 # Commit It
@@ -14,7 +14,10 @@ and reread its current source and relevant references before use. Follow applica
 repository instructions, including AGENTS.md and CLAUDE.md, without replacing them.
 For requested changes to the skill itself, update the canonical source through its
 configured local maintenance workflow. Preserve concurrent edits and do not create an
-independent provider copy. Ordinary policy edits do not select a new release version.
+independent provider copy. When the user authorizes autonomous version maintenance, choose a semantic version
+bump when verified changes warrant one; do not bump merely because a conversation
+changed. Keep metadata, release notes and consumer pins consistent. Tag and Release
+publication remain separately authorized; see docs/releasing.md.
 
 ## Boundaries
 
@@ -95,6 +98,15 @@ do not invent issue numbers, links or completion. Leave the useful handoff recor
 GitHub, including remaining work and links, rather than requiring the next agent or
 human to reconstruct it from chat.
 
+Public OPS records use one concise heading and canonical Markdown fields/nested lists,
+readable by humans and strictly parsed by tools. Do not publish JSON fences, raw payload
+dumps or a second hidden JSON copy of the same metadata. Each datum has one authoritative
+field; link detailed evidence instead of repeating it. Follow the
+[record format and migration contract](references/worker-coordination.md#public-record-format).
+Normal runtime reads reject legacy JSON; only an explicitly authorized, audited migration
+may convert existing OPS-generated records in place. Preserve authors, IDs and semantic
+values, exclude human/unmanaged content, and never rewrite Git commits or history.
+
 ### Issue body format
 
 Use the following English structure for new actionable issues and substantive scope
@@ -375,18 +387,27 @@ only for an eligible request or an explicit user-approved exception.
 
 - Ordinary review requires the implementing worker's durable request and takes place
   in a different conversation/task, strictly within that implementation scope. Record the
-  requesting worker, implementation task, reviewer task, PR, head/base and outcome. A
-  changed worker name in the same conversation does not satisfy task separation. Do not
+  requesting worker, implementation task, reviewer task, PR, head/base and outcome. The
+  requested separate reviewer directly repairs clear defects within that implementation
+  scope on the same PR by default, then verifies and publishes the final result. A changed
+  worker name in the same conversation does not satisfy task separation. Do not
   spawn a new task without the runtime's required user authority; record a pending request.
 - Self-review is prohibited for ordinary workers unless the user explicitly approves it
   for the named scope. An implementing worker cannot approve its own exception. This
-  exception does not claim independent authorship or human review. A successor taking
-  implementation ownership follows the same rule, including for inherited code.
+  exception does not claim independent authorship or human review. An implementation
+  successor follows the same rule. A requested separate reviewer who makes bounded repairs
+  is instead disclosed as reviewer-as-contributor under the repair protocol; it cannot
+  claim independent review of its own corrections.
 - Reuse implementation/test evidence and inspect only the requested diff and direct
-  contracts/callers. No proactive unrelated review or wider audit is implied. Verification
+  contracts/callers. Before repair, pause the original writer, declare files/scope and
+  expected head/base, remove `MERGE_READY`, and use Draft/`OCCUPIED`. Commit and ordinarily
+  push scoped fixes personally to the same PR; OPS records the contribution and final
+  head. Leave change requests/questions only for complex intent, material scope changes,
+  unresolved authority or ambiguity. No unrelated review or wider audit is implied. Verification
   and final diff/scope checks remain part of implementation; they are not a PR approval.
 - Authorized successful reviews start exactly with `Review: LGTM` for a separate reviewer,
-  `Self-review: LGTM` for explicitly user-approved self-review, or `Conflict resolution: LGTM`
+  including disclosed repair-review when it contributed corrections, `Self-review: LGTM`
+  for explicitly user-approved original-worker self-review, or `Conflict resolution: LGTM`
   for an explicitly granted resolver review under [conflict resolution](references/conflict-resolution.md).
   Preserve historical headings; use a concrete `Changes requested` outcome for blockers.
 - A valid review plus current passing checks and matching PR head/base permits adding

diff --git a/docs/releasing.md b/docs/releasing.md
@@ -8,7 +8,10 @@ Before a release, inspect current source, relevant installed variants, assigned
 and related PRs. Reconcile completed changes without taking over active work. Choose
 the next version only after scope and verification are known: compatible fixes use
 patch, additive behavior uses minor, and incompatible documented interfaces use major.
-Follow [Semantic Versioning](https://semver.org/).
+Follow [Semantic Versioning](https://semver.org/). When the user has authorized autonomous
+version maintenance, make this decision and update metadata, release notes and verified
+consumer pins without asking again. A version-only bump without a meaningful change is
+unnecessary. This authorization does not itself publish a tag or GitHub Release.
 
 Commit subjects follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)
 and repository templates. Ordinary changes describe shipped behavior; a dedicated

diff --git a/references/conflict-resolution.md b/references/conflict-resolution.md
@@ -54,11 +54,12 @@ this mode. User and repository authority still govern every action.
 
 ## Durable sequence record
 
-Keep one canonical, editable comment marked `commit-it:merge-sequence:v1` on a named
-anchor PR. Store its comment ID or URL in the participating PR records. Continue
-updating that same comment after the anchor PR merges: its body, old commit messages
-and status mirrors do not replace the canonical sequence. Reconcile duplicate records,
-missing write access or partially applied updates before advancing.
+Keep one canonical, editable OPS v2 merge-sequence record on a named anchor PR.
+Store its comment ID or URL in participating records. Continue updating that same record
+after the anchor merges. Preserve exact schema keys and IDs; old JSON bodies, commit
+messages and mirrors do not replace it. Reconcile duplicates, missing access or partial
+writes before advancing. Runtime readers accept the current strict Markdown format;
+legacy JSON is available only to the explicitly authorized audited migration.
 
 The existing `Work status` model remains `OCCUPIED` / `REVIEW_READY`. Record the separate
 `Merge status` here; do not substitute merge states for worker states or treat a PR's
@@ -74,42 +75,35 @@ it does not replace Work status or authorize the sequence.
 | `MERGED` | Every planned step has a verified real merge receipt and resulting tree. |
 | `BLOCKED` | An unresolved authorization, ownership, check, state or receipt mismatch prevents the next step. Preserve completed work and the exact resume action. |
 
-Illustrative record; resolve placeholders before publication. During preparation,
-name unavailable evidence explicitly rather than inventing SHAs or passing results.
+Use the configured OPS schema/renderer for the complete write payload. This is a
+non-executable excerpt showing canonical lowercase fields and nested lists, not a full
+copyable record. The renderer supplies the type-specific v2 marker, required repository,
+authorization, anchor, PR snapshot and receipt fields. Never guess missing fields or SHA values.
 
 ```markdown
-<!-- commit-it:merge-sequence:v1 -->
-
-- Sequence: <stable sequence ID>
-- Revision: <revision>
-- Role: conflict-resolver
-- Resolver: <actual worker ID>
-- Merge status: PREPARING
-- Base: <base branch and full SHA>
-- Order: <ordered PR URLs>
-- Completed: <PR, merge SHA and resulting tree receipts, or none>
-- Next: <next unmerged PR URL, or none>
-- Readiness scope: next-step-only
-- Ready PR: <verified next PR URL, or none>
-- Pending verification: <later unverified PR URLs, or none>
-- Authorization: <verified grant, named PR set, allowed actions and merge method>
-- Resume: <next action or concrete blocker>
-- Updated: <UTC timestamp>
-
-| PR | Head | Expected base | Verified tree | Evidence |
-| --- | --- | --- | --- | --- |
-| <PR URL> | <full head SHA> | <base SHA or planned predecessor/tree> | <full expected result tree SHA> | <checks, inputs/environment and review references> |
-
-<!-- /commit-it:merge-sequence -->
+### Merge sequence
+
+- schema_version: 2
+- id: <stable sequence ID>
+- role: conflict-resolver
+- resolver: <actual worker ID>
+- revision: 1
+- status: PREPARING
+- order:
+  - <first PR number>
+  - <next PR number>
+- prs: {}
 ```
 
-Every planned PR needs a head/base/tree/evidence row, with unavailable future evidence explicitly pending. `MERGE_SEQUENCE_READY` applies only to `Ready PR`, which must equal `Next`; after its receipt is saved, clear readiness and verify the next step against the new actual base. Start from the recorded full
-base SHA. A later step may identify its planned predecessor and expected base tree
-until that merge exists; bind its actual base SHA from the verified receipt before
-execution. Never predict a future merge SHA. `Completed` records actual merge
-results, not requested merges. `Next` must follow the remaining order and cannot
-name an already completed PR. Include each dependency in the plan and verify that its
-required tree is present before advancing. Keep detailed logs behind evidence links.
+Every planned PR needs a snapshot with exact head, expected base/tree and evidence in
+the schema's `prs` structure; missing future evidence is explicitly pending. Readiness
+applies only to the next named step. After its receipt is saved, clear readiness and
+verify the next step against the actual new base. Never predict a future merge SHA or
+repeat a completed step. Preserve actual merge commit/tree receipts and dependency
+order. Reference the original approval record and store its hash rather than copying
+the full approval body into the sequence. Link detailed logs instead of repeating them.
+Follow the [public record contract](worker-coordination.md#public-record-format): one
+readable canonical payload, no JSON fence or hidden duplicate, no runtime legacy fallback.
 
 ## Commit and squash metadata
 
@@ -155,16 +149,11 @@ Only the explicitly assigned resolver with an explicit scoped review/self-review
 may publish this exact first line for its verified integration scope. Without that grant,
 stop at `REVIEW_READY` and use the ordinary requested-review path:
 
-```markdown
-Conflict resolution: LGTM
-
-Resolver: <actual worker ID> · Role: conflict-resolver
-Sequence: <ID> · Revision: <revision>
-Reviewed head: <full SHA> · Base: <full SHA> · Verified tree: <full SHA>
-Verification: <executed checks and clearly attributed reused evidence>.
-Original authors: <source PR/worker provenance>.
-No blocking findings in the assigned integration scope.
-```
+The first line remains exactly `Conflict resolution: LGTM`. The guarded OPS renderer
+records the resolver, role, sequence/revision, original authors, head/base/tree and
+verification once using the conflict-approval schema's exact keys and v2 marker. Link
+that approval from the sequence instead of duplicating its body. Do not publish a
+handwritten partial field set as a valid structured approval.
 
 This has the same evidentiary approval level as `Self-review: LGTM` and `Review: LGTM`:
 complete scope and passing required evidence for the recorded snapshot. It identifies