21 October 2026

A Reusable Review Procedure for Clankers

(Distilled/discovered from clanker-based editing processes for a lengthy personal writing project. To use: first, identify a possibly long list of concerns via an LLM. Second, tell it you want to apply this procedure via its URL.)

How to run a structured review, independent of what you are reviewing. A checklist (copy.md, conceptual.md, or any other) supplies the what — the concerns to look for. This supplies the how — the cadence that turns a pile of concerns into a converged, auditable result without churn. It applies to prose, code, specifications, designs — anything revised by identifying concerns and proposing changes.

Two roles run through it. The owner decides; the reviewer proposes and reasons. When they are the same person, the roles still separate in time — propose, then decide. Both feed the same proposal stream.

Fix the scope and mode before starting. Scope is the review’s unit — a section, a file, a function — with how far out to load context: the neighbors it hands off to, the parent it sits within, the targets it references. Mode is whether changes are applied as you go: a full review edits and verifies in place; a review-only (dry-run) pass runs every applicable check and produces the log but touches nothing — for a second reviewer, a pre-flight, or a hand-off.

1. Identity: label everything

Nothing downstream works without stable identity, because every later step refers to items by name.

  • Enumerate and name concerns. A concern is one problem to solve, surfaced as a discrete decision point — a claim, a reason, and where possible a proposed fix — not a vague category.
  • File a root objection once. One objection often bears on several passages, and raising it at each makes the owner decide the same question several times and inflates the false-positive count when it proves wrong. File it under the one concern that owns it; elsewhere, cite that label rather than restating the objection.
  • Label what the checklist did not raise. Work surfaced in conversation — by the owner, or falling out of another concern — gets a label and a disposition like anything else, in its own series so its provenance stays visible. A register that carries only the checklist’s items silently claims the checklist found everything, and the unlabelled work is what dissolves back into the transcript when the register is archived.
  • Concern label (C1, C2, …): stable, assigned once, never reused or renumbered. One lifecycle per concern: open –> resolved / accepted / deferred / rejected.
  • Proposal sublabel (C1.1, C1.2, …): a candidate resolution. Author-agnostic and monotonic — whoever floats a candidate, it takes the next number under that concern. A distinct draft is a new sublabel, however small the change, so the trail of tried-and-rejected drafts survives. Nest deeper (C1.4.2) only when a proposal itself forks.
  • Sublabel zero is reserved (C1.0): not a candidate but an analysis of what the passage is for and what it is entitled to claim (Section 2). It takes a number so the owner can call it like any other option and so the log records whether it ran, but it is never applied — there is nothing in it to apply. Candidates keep numbering from .1 whether or not zero was run.
  • Retiring is a candidate, not the absence of one. “Leave it as written” takes the next sublabel like any draft, so the owner can select it by number instead of by prose and the log records who proposed it and on what ground. A concern settled that way closes rejected when the finding was wrong, and accepted when it was right and the owner keeps the text anyway (Section 7). Either way nothing reached the work, and the retire sublabel is marked accepted. The two are not in tension: the disposition describes the concern, the sublabel describes which resolution won.
  • A label is not a location. Coordinates (line, paragraph, page) drift as edits land; the label is the stable key and the location is a mutable attribute re-derived on demand (see Section 5).
  • Never write a coordinate into the work itself. Annotations that ship with the material — source comments, marginalia, editorial notes — outlive the review that produced them and drift the moment anything above them is inserted or cut, going silently wrong rather than merely stale. Refer to content instead: “the footnote below”, “the second ‘frequently’”, the quoted phrase. The register may carry coordinates because Section 5 re-derives them on demand; the work may not, because nothing re-derives the work.
  • Name the material in its own vocabulary. Identify the units under review by identifiers the material already carries — its labels, headings, block markers, function names. Where it carries none at the granularity you need, coin a semi-stable identifier from the content: a short descriptive name, or a distinctive quote (Section 5). Coining is fine; the test is stability, not provenance. What fails the test is any positional metric — a paragraph index, “the third bullet”, a section number you numbered yourself — because position moves the instant anything is inserted or cut. A bare deictic like “here” or “the next one” is worse still, having had no referent to begin with. The owner can resolve none of these and must guess or stop and ask; a proposal the owner cannot judge is worse than no proposal. This binds the reviewer, who reads the whole and finds any shorthand obvious, far more than the owner.
  • Labels are the join key for the ordering, the log (Section 6), and every reference in discussion. “Apply C4, revert C2, C6 depends on C1” then becomes a one-line exchange.

2. Propose straightforwardly

  • Claim, reason, fix. Every proposal states what is wrong, why it matters, and a concrete remedy. The reason is what lets the owner judge rather than rubber-stamp.
  • Open a concern with the text itself. Quote the offending material as a blockquote before any analysis of it, verbatim and long enough to read without the surrounding page. The owner then judges the finding against what is actually written rather than against the reviewer’s paraphrase, and a concern whose quote plainly does not look wrong is dismissed in a glance instead of after a paragraph of argument. This also fixes the division of block types: a blockquote is what the work says now, a fenced diff is what a candidate would make it say (Section 4). Quote the same anchor the log records, so the register and the conversation cannot drift apart.
  • Offer a purpose analysis as sublabel zero; never run it unasked. A word-level flag is sometimes the visible end of a missing idea rather than a cosmetic fault, and nothing in the wording says which. So list C1.0 above the candidates: an analysis of what the passage is for, what it is entitled to claim, and whether the flagged text does that job. The owner spends a turn on it when a concern smells deeper than its label; otherwise the candidates stand and the offer costs a line. Running it by reflex would spend that turn on every article and comma, which is how a false-positive budget gets eaten by the findings that were fine. Report plainly what running it did — it can retire the candidates beneath it, replace them, or leave them standing. Where the passage’s job cannot be stated in a sentence, say so: that inability is the finding, and it is usually worth more than any of the drafts.
  • Ground a specialist objection in the specialist’s sources before proposing a fix. When a finding turns on what a field means by a word, the reviewer’s model of that field is the least reliable input in the pass, and it is invisible as such: an off-the-cuff take reads exactly like a sourced one. Check the field’s own literature first, undergraduate texts especially, since what the median practitioner was taught sets the tone more than what the specialist literature currently argues. Expect three outcomes, all useful: the finding survives, the finding dissolves, or — the one worth the cost — the finding is right that something is wrong and wrong about which way it runs, and the grounding turns it into the real one. Feed what you learn back into the reader profile, or the same false finding is regenerated next pass.
  • Ground usage in the work itself before any outside source. A finding about register, tone, idiom, or vocabulary is a claim about the work’s own voice, and the work is the cheapest and most authoritative witness to it. Search it for the device, the word, or the construction before raising the finding; a precedent elsewhere in the work usually retires it. Inventory the current text, not a memory of an earlier draft. The same search serves drafting: when candidates keep missing, the word the work already uses for the idea often sits in a neighboring unit.
  • Budget false positives, and fix the method rather than the threshold. The target is not zero findings; it is a low share of wrong ones. Record the rate in the log — findings raised against findings that survived — because the number is invisible from inside a pass, where every finding felt reasonable when written. When it runs high, stop and diagnose before surfacing anything further, and write the correction from all the instances at once. A rule drafted from the first error is fitted to that error and will not catch its siblings; the pattern only shows once the set is complete. Then re-screen every open finding against the correction before presenting the next one. Findings raised under the old method carry its error, and the re-screen dissolves them for the price of a read rather than a decision round each.
  • Decompose a claim before matching it to a source. A sentence usually makes several claims, and a provenance finding raised against the whole is really a finding against one part — or against none, once the parts are checked separately. Split first, then look for each part on its own. The half that carries the argument is the one most often skipped, because it is the half that reads as obviously true.
  • Match against the primary, not against your notes on it. A reference file, bibliography annotation, or earlier summary is a finding aid, not evidence. Surface similarity to a paraphrase is not similarity to the source: read the passage the note points at before asserting that the work tracks it, borrows from it, or owes it a citation. Summaries compress toward the reviewer’s own phrasing, which is exactly what makes them look like a match, so a match against a note is weak evidence in either direction.
  • A match is agreement of claims, not of topic. Lexical or topical overlap is where a search starts, never what it concludes. Two passages match when they agree on four things: what is claimed, about what object, by what mechanism, and at what phase of the thing’s life. Name all four for each side before asserting any relation. Divergence on one of them turns the finding from borrowing into convergence. Say which it is; whether the convergence matters is the owner’s call, not the reviewer’s. The failures to look for: same verb different object; same principle different mechanism; same duty at a different phase, protecting the writing of a thing against protecting its use; and shared material that turns out to be a general proposition no source owns.
  • Check a finding before raising it, and aim at the truth rather than at the finding. The filtering duty above covers candidate fixes; it covers findings too. A concern reported from resemblance alone is a suspicion, and putting a suspicion to the owner spends a decision round on the reviewer’s unfinished homework. So run the four-part test above before writing anything — but run it neutrally. When the finding is a counterexample, read the claim’s quantifier, direction, and object before matching the case to it: a case that fails “some” does not fail “every”, detecting a difference is not concluding sameness, and a case against how a thing is done does not touch what it implies. Checking confirms as readily as it dissolves, and a finding that has been checked arrives stronger, with the reason it holds already in hand. Report what the check found either way, including when it strengthened the case. Do not set out to disprove: that is the mirror of the error it corrects, and it suppresses true findings as reliably as credulity manufactures false ones. A pass that surfaces nothing has probably not looked.
  • Present only un-ruled-out options. The reviewer does the filtering: what is dominated (strictly worse than a survivor) or violates a hard constraint gets ruled out and logged, not laid before the owner. What remains is genuine tradeoffs; when one clearly wins, present a lean, not a menu.
  • Surface a re-proposed dead end. When the owner independently floats a candidate the review already ruled out, neither silently accept it nor re-derive from scratch — match it to its logged sublabel and give the recorded reason (“that is C1.2, set aside because …”), framed as revisable, since the owner may bring new information that retires the reason. This is the complement of filtering: options are ruled out of the presentation but their reasons stay retrievable, so a rediscovered dead end is answered from the log in one line rather than re-argued.
  • Expose the open surface with every decision request. Ask the owner to decide only alongside a statement of what is still open: the concern, the live alternatives, and whatever already-settled material the choice depends on. A reviewer accumulates state the owner never saw — superseded drafts, closed branches, notes taken between rounds — and a bare label (“decide C4.12”) exposes none of it, forcing the owner to reconstruct the register or guess. Keep the surface small by closing branches, never by withholding them. If more than one alternative is live, give each a sentence; if they will not fit in a sentence apiece, the concern needs splitting rather than summarizing.
  • Put the decision request where it cannot be missed. A request buried in a closing clause — “say the word and I will”, “let me know if you want” — reads as a pleasantry rather than as a question, especially at the end of a long analysis the owner has just finished absorbing. The owner then either overlooks it or must re-scan to find what is being asked. State the open decision first, in its own line, phrased as a question with the options named. The analysis that justifies it belongs after, where the owner can skip it if they have already decided. This is the presentation half of exposing the open surface: the surface is useless if the owner has to hunt for it.
  • Surface what dissolved; do not merely log it. A concern that later decisions render moot is closed by inference rather than by the evidence that raised it, and that inference is the reviewer’s own, unchecked. Put it before the owner with its derivation: what raised it, which decision absorbed it, and what would reopen it. Anything that caught the reviewer’s eye is worth the owner’s glance if only as a double check — the owner is the guard against a reviewer who has talked themselves out of a real finding. The cost is a sentence; the failure mode is a genuine concern vanishing quietly between two unrelated rulings.
  • Prefer a decision you can grep. Where a ruling reduces to a mechanical check, record the check beside it — the reserved word, the required column, the pattern that must not appear, the form that must. A greppable constraint survives fatigue, delegation, and the months between deciding and drafting, and it lets a later pass confirm compliance without re-deriving the reasoning that produced it. Scope the check to live text. A count that sweeps in commented-out drafts, rejected sections, or the review’s own notes overstates precedent, and filtering the matched fragments rather than the source lines lets them back in unnoticed. Most interesting decisions resist this and stay judgement calls; that is fine. But reach for the mechanical form first, and where two formulations are otherwise equal, prefer the one that admits a check — checkability is a legitimate tie-breaker, not merely a convenience.
  • Name the operative principle. When a recommendation rests on something beyond the obvious, name it. That lets the owner judge the principle, not only the instance — and reuse it. Named principles are how a review compounds instead of evaporating; they are the raw material of the next checklist.
  • Triage: fix vs propose. Objective errors are fixed directly; matters of taste, voice, or owner judgment are proposed. Mis-triaging a taste call as a fix oversteps.

Ruled-out and rejected candidates are not discarded — they go to the audit log as sublabels with a reason (Section 6). Lean surface, complete record.

3. Order the work

The order you take concerns in decides how much effort you waste.

  • Primary sort: dependency. Do the changes that reshape the work — those that would invalidate other pending changes if done later — before changes that merely polish. Polishing something a later change rewrites is wasted effort, and worse, it anchors you to material you should have cut. This axis dominates the others.
  • Secondary sort, within a dependency tier: merit, impact, simplicity. Among changes that do not affect one another, favor those most likely to be accepted, with the largest effect on the result, and the cleanest fix.
  • Momentum is a tier-internal choice, not a cross-tier one. Cheap, certain wins build flow — take them first within a tier if you like, but never let them jump ahead of a reshaping change that sits in an earlier tier.
  • Phase the tiers, coarse to fine, and keep each small. Small phases bound the blast radius, which keeps the drift you must re-confirm against (Section 5) local and cheap. Reconcile a phase before advancing.
  • Confirm by deciding. Do not give a concern a separate verification step that merely restates the step that decided it. Fold verification into the phase that settles the concern, or into the first phase where its inputs are stable. A concern earns a second phase only when it has a genuine reshaping facet and a distinct fine facet that needs more stability — otherwise the second pass is false re-review.
  • Scope the checklist to the unit. Not every check applies to every unit. Run the ones the material can actually trigger — heaviest-yield first — and mark the rest not applicable (they are still coverage; Section 6). A claim in a specialist’s domain needs that specialist’s pass; a plain prose beat needs none. Do not spend the most expensive pass where the material cannot move it.

4. Apply a change

  • Separate the vocabulary of discussion from the vocabulary of application. Two distinct requests share most of their natural phrasing, so fix a word for each at the start and never let one stand for the other. Discuss, assess, compare, spec out ask for reasoning in the conversation and touch nothing. Exhibit, apply, make the change, edit ask for the change in the work, where it can be diffed and reverted. Words that straddle — “show”, “give me”, “let’s see”, “what about” — name neither. Treat a straddling word as a question, not as a coin flip: ask which is wanted before acting. The cost of asking is one line. The cost of guessing wrong is asymmetric — applying when discussion was wanted leaves the owner reviewing and reverting work they never sanctioned, while discussing when application was wanted costs only a round trip. So where asking is somehow impossible, guess discussion.
  • Label every shown block by its state. Proposal text and applied text look identical on the page, so the owner cannot tell which they are reading without opening the file — and the two ask for different work, judging against auditing. Head each block with PROPOSED when nothing is going to disk, APPLYING when the edit is about to run, and APPLIED once it has landed, naming the file it landed in. Put applied results first in the message, before any discussion of what comes next, so the top of every reply answers what changed before it asks what next. This is the presentation half of separating the two vocabularies above: fixing the words is useless if the owner cannot see which one is in force.
  • Carry the sublabel in the state marker, and render the change as a diff. A bare PROPOSED tells the owner what kind of block they are reading but not which candidate it is, so accepting one costs a sentence of description rather than a label. Head every candidate PROPOSED AS C1.2, name the file, and show the change itself as a machine-generated diff rather than as quoted prose: proposal text set as a blockquote reads like the analysis around it, and markup is mangled in the bargain. Two blocks, in this order: a line diff for the shape, so the owner can read each version as prose, then a word diff (git diff --word-diff=plain, [-removed-] against {+added+}) for the substitution, so a near-identical line cannot slip past. Give the pair to the candidate you lean toward; give the alternatives whichever single block carries more — the word diff for a substitution inside a surviving sentence, the line diff for a wholesale replacement. A candidate that changes nothing, such as accept, gets no block and says so, since an empty diff is noise.
  • An insertion needs its neighbours. A pure addition has nothing to diff against, so a word diff of it shows the new text and no location — the owner is told what would be added and not where, which is most of what they are being asked to judge. Show an insertion as a line diff carrying at least one unchanged line on each side, and skip the word diff, which for an addition only repeats the line diff inside markers. Where placement is itself the question, widen the context until the alternatives are visible.
  • Scope a diff to the sentence, never the paragraph. Hand-wrapped prose reflows, so a three-word change rewrites every line after it and the diff shows six changed lines for one changed word. Diff the affected sentence alone.
  • Reflow is invisible work, and it waits for a clean board. Rewrapping, sentence spacing, column limits, and the artifacts they produce in a diff are the reviewer’s problem, not the owner’s. They are also never a concern while any entry is outstanding. Wrapping is downstream of content: every later edit rewraps whatever an earlier one tidied, so fixing it mid-review is work a subsequent concern undoes, and it inflates each diff with lines the owner did not change. Defer it until the register is clean, then take it in one pass. Until then, do not fix it, do not apologise for it, and do not let a ragged line in a shown diff become a topic — if the owner raises wrapping while concerns are open, say it is parked and move on. Never spend a line of the owner’s attention narrating a wrap, or explaining that a word diff fragmented because the wrap point moved. The only reflow worth mentioning is a mistake that reached disk and was corrected there, and then only as one clause inside the applied note.
  • Generate the diff; do not type it. A hand-written diff can disagree with the edit it claims to describe. Produce it against a scratch copy of the file so what the owner reads is what would land.
  • An argument for a change is not approval of it. When the owner supplies a reason a proposal is right — “hypotheses are records”, “that word is used elsewhere” — they are reasoning toward a decision, not announcing one. The trap is timing: a bare justification arriving right after a decision question reads like an answer to it. The tell is the absence of any verb aimed at the work. Reasons, reframings, and counter-proposals all mean keep discussing. Terseness is not the signal — “take it” and “B” are terse and decisive. The asymmetry above governs, so re-ask in one line.
  • Moving on is not a ruling. “Next”, “continue”, or a fresh question arriving while a decision is pending advances the review; it does not settle the pending item. Record the item as pending, say so in one line, and ask. An owner who wants it closed will say so, and a closure inferred from momentum is the silent disposition Section 7 forbids.
  • Serialize for control; batch only the independent and settled. When the owner must weigh each change, take them one at a time. Batch only changes that are mutually independent and already decided.
  • Apply, then verify. After each change, check the mechanical result — that nothing was dropped, split, or broken by the edit itself. Verification catches the actor’s own slips, not just drift.
  • Leave cosmetic reformatting to a formatter. Reflow, rewrap, whitespace, and the like carry no review value; do not spend proposal or verification effort on them, and do not let them churn the diff. A separate automated pass owns them.

5. Stay current: freshness and drift

The work changes under you — from your own edits and from the owner’s out-of-band ones. Two guards keep you from acting on a stale view.

  • Freshness guard — per file. Record a file’s modification time or content hash when you read it. The trigger to re-read is that file’s own change, not the tree’s: a different file moving, or a blanket “the tree was touched” signal, is no reason to re-read this one, and re-reading everything on any tree modification bogs the review down. Before acting on a file, re-check it; if it moved, re-read and diff before proceeding — including the owner’s commits to that file (git log -- <file>), since a clean git status does not mean it is unchanged if the owner committed out-of-band. An external edit is a change event like any other — log it (Section 6). This is “apply, then verify” pointed at the input: confirm the material is what you think before you touch it.
  • Anchor concerns to content, not coordinates. Pin a concern to a distinctive quote or a stable landmark, never to a number that renumbers.
  • Re-confirm at point of use. Before acting on a pending concern, re-check both that it is still relevant — an earlier change may have fixed it, or created a new one — and where it now lives — the referent may have moved, or changed shape, as when one unit splits into two. If the anchor is gone, the concern is resolved-or-transformed, not merely relocated.
  • Sweep the open concerns this way after any change to the material and at the close of each phase. Small phases keep that sweep local.

6. The log

The log is a concrete artifact kept beside the work, never inside it — a scratch file, an issue list, an editor’s quickfix window: whatever holds a navigable register of located items. It lives under audits/ at the root of the work, one file per review, named <YYYYMMDD>-<unit>-<source>.md so the unit, the date, and the checklist that drove it are visible without opening it. It is shared state the owner may read at any moment, not the reviewer’s private notebook; and its existence never substitutes for stating what is open at the point of decision (Section 2). It is to a review what a Vim quickfix list is to an edit session: a separate window of entries, each carrying a location and a message, that you populate from your passes, step through, jump to, act on, and mark — so the review is driven by working the register, not by memory. It is born when the review starts, grows as concerns are called out (Section 1) and dispositioned, is reconciled at close (Section 7), and is then archived or discarded. It can outlive the review as provenance — these checklists were themselves extracted from one such log.

Keep the log’s upkeep out of the conversation. Report the work — what changed, what is open, what is asked — and let the log absorb its bookkeeping silently. Narrating each entry spends the owner’s attention on the register instead of on the decisions it serves, and the owner can read the log whenever they choose.

One record, two indexes into it, both keyed by label:

  • By label — the audit view. One entry per concern: its label, where it arose, its disposition (addressed / deferred with a reason and a revisit trigger / rejected with a reason / superseded — dissolved by another concern’s resolution rather than decided on its own merits, naming the absorbing label / outstanding), and a one-line resolution note. Proposals hang under it as sub-entries, each with its own disposition, author, and derivation (C1.4 = C1.2 + change; C1.4 supersedes C1.1). Rejected alternatives are recorded, not dropped, so a later reader — or the owner rediscovering a dead end — sees the roads not taken. This view is the completeness check: at close, no entry may remain outstanding.
  • By location — the churn view. Per-location edit history, keyed by the applied label. A new proposal touching a location that already carries an applied label is a revisit signal; if it reverts that prior label, that is oscillation, as opposed to legitimate revision — “we are undoing settled work” made visible instead of left to memory. Like a quickfix list, this view goes stale when the material shifts underneath it, which is why locations are re-anchored on demand (Section 5) rather than trusted as stored coordinates.

Two completenesses. The views above prove resolution — every concern closed. They do not prove coverage — every check applied — because a check that passes raises no concern and leaves no entry. Track coverage in its own right: each check the unit’s scope admits is run and marked passed, concern-raised (with the label), or not applicable. Report coverage even when it is null — “ran the audience pass, nothing found” — so a clean review still shows its work and progress stays visible. On a mature unit the findings list is nearly empty while coverage is large; only reporting both keeps that honest. A concrete layout for coverage, concerns, and churn together is in the Appendix.

7. Close: reconcile and converge

  • Reconcile the log. Read the whole once, for coherence and for regressions from earlier changes. Then walk the log: every concern is addressed, accepted, deferred, or rejected — and call out by name any concern that fell unaddressed, and resolve or deliberately defer it. Silence is not a disposition.
  • Keep accepted distinct from rejected. A concern is rejected when it turns out to be wrong. It is accepted when it is right and the owner chooses to live with it — a real cost, knowingly paid, not coming back. Collapsing the two erases the difference between “we checked and it was wrong” and “we agreed and moved on”, which is most of what a closed register is later read for. Record the owner’s ground either way; an accepted concern without its ground reads as an oversight to whoever finds it next.
  • Prove stability. Repeat the read after the reconciliation’s changes. A converged result surfaces nothing new. If it does, the work has not converged: log it, address it, repeat.
  • Stopping condition: a stability read that raises nothing new over a log with no outstanding entry. That, not exhaustion, is done.
  • Vacuity. If the reconcile produced no edits — a review-only run, or a clean full review — the stability read is vacuously satisfied: nothing changed to destabilize it. Record it passed; do not skip it in silence.

Pairing with a checklist

The checklist and the procedure are orthogonal. A checklist names what to look for and may itself be tiered by dependency: its phases become this procedure’s dependency tiers, its categories become the concern taxonomy. This procedure names how to run the pass over it. Run a reshaping checklist before a polishing one for the same reason you order concerns by dependency — do not polish, or copyedit, material a deeper pass will restructure.

Appendix: log format

One register per review, kept under audits/ beside the work. Its sections mirror the procedure — coverage (Section 6), concerns (the audit view), churn (the churn view), close (Section 7). The shape matters, not the syntax; adapt it to the tool at hand. Wrap the register at 79 columns, as the rest of the repository wraps: a log that reflows differently from the work it tracks is harder to read beside it and harder to diff.

# Review log --- <unit>
scope:    <what is in>; context loaded: <neighbors / parent / referenced targets>
mode:     full | review-only
baseline: <commit or mtime at start>        # freshness anchor (Section 5)

## Coverage        -- every check the scope admits; the record of effort
<check or phase> : pass | C<n> | n/a (<why>)

## Concerns        -- audit view, keyed by label
[C1] <short name>  (phase <n>)  <open|addressed|deferred|rejected|outstanding>
  anchor: "<distinctive quote or landmark>"     # re-derive location from this
  note:   <one line: resolution, or reason to defer/reject>
  C1.0 (reviewer): purpose analysis  -- offered | run (<what it settled>)
  C1.1 (<author>): <draft or approach>  -- rejected (<reason>)
  C1.2 (<author>): <draft or approach>  -- accepted   [supersedes C1.1]
  C1.3 (<author>): retire, leave as written  -- rejected (<reason>)

## Churn           -- by location; only entries touched more than once
"<anchor>": C1.2 applied ; C4.1 applied (revisit) | reverted by C7.1 (oscillation)

## Close
outstanding: <count -- must be 0 to converge>
stability:   clean (nothing new) | not converged | vacuous (no edits)

Filled from the review-only dry-run of this procedure over sec:perturbation:

# Review log --- chapters/execution.tex : sec:perturbation
scope:    the section; context: chapter intro, siblings (methodology, baseline), 6 \ref targets
mode:     review-only
baseline: ebf6644

## Coverage
phase 1 context      : pass
phase 1 audience     : pass (7 personas, none tripped)
phase 1 argument     : pass
phase 1 forward-refs : pass (all six refs point backward)
phase 1 structure    : C1
phase 1 footnotes    : pass (2 notes, both merited)
phase 2 claim        : pass
phase 2 motif        : pass
phase 2 terminology  : pass ("prior" collision gone since revert to "past")
phase 3 craft        : pass
phase 3 cross-ref    : C2
phase 3 voice        : pass ("often" at P2 consciously kept)

## Concerns
[C1] vetting-method beat: length / possible split at "A promising result that survives"  (phase 1)  deferred
  anchor: "To do this vetting, vary the choices you would otherwise leave unexamined"
  note:   two beats but tightly coupled; not worth a split
  C1.1 (reviewer): split it into probe / interpretation  -- rejected (coupling too tight)
[C2] irreversibility framing carries three \ref in five lines  (phase 3)  rejected
  anchor: "cost (Section~\ref{sec:longideal}).  High-stakes applications"
  note:   each anchors a distinct claim; not over-referencing

## Churn
(none -- review-only)

## Close
outstanding: 0
stability:   vacuous (no edits)

Provenance

Distilled from a long collaborative revision in which the process became as much the product as the text. It is deliberately domain-neutral: the same cadence runs a copyedit, a conceptual edit, a code review, or a spec review. Extend it as new kinds of friction surface.

No comments:

Post a Comment