Skip to content

docs: fix #431's false snapshot sentence; record the second-copies rule and review ritual in CLAUDE.md - #513

Merged
blooop merged 2 commits into
mainfrom
docs/431-honest-snapshot-sentence
Aug 29, 2026
Merged

docs: fix #431's false snapshot sentence; record the second-copies rule and review ritual in CLAUDE.md#513
blooop merged 2 commits into
mainfrom
docs/431-honest-snapshot-sentence

Conversation

@blooop

@blooop blooop commented Aug 29, 2026

Copy link
Copy Markdown
Owner

CLAUDE.md changes in here: the second commit adds a standing-rules section to AGENTS.md (which CLAUDE.md symlinks to), recording two decisions that were resolved on their tickets and never written down. It is a separate commit so it can be read on its own.

1. docs/development.md: say where a hand-edited snapshot is actually caught (#431)

The snapshots section told a contributor that a hand-edited snapshot "fails in the Rust suite rather than in review". It does not. public_api_snapshots.rs holds the partition (every row in exactly one file, promise rows at an api path), and ordering is not a partition property, so #427's misordered public-api.rest.txt passed 4/4 locally and was rejected by CI's public-api job three hours later. Since cargo-public-api needs nightly and a pinned version, the devcontainer cannot regenerate at all, which makes hand-editing the normal path in there rather than an exception.

The sentence now says which half is caught where, and that a hand-edit is provisional until the public-api job agrees.

Option two on the ticket, teaching the Rust test the generator's ordering, is not taken. The ticket's own condition was that the rule be shown to be derivable first: cargo public-api's order is its own, not plain sort, and encoding a guess would be worse than the gap it closes. Option three (regeneration inside the container) stays rejected for the reason the ticket names, that it needs nightly plus a pinned tool and any .devcontainer/ change invalidates the prebuild.

2. CLAUDE.md: two standing rules (#319, #321, #323)

Both were decided and closed on their tickets, with the closing comments saying "recorded in CLAUDE.md (PR to follow)". This is that PR.

  • Second copies (A standing rule for second copies of one fact #319, with Generated vs hand-written bash completions #321 as the worked example): a second hand-maintained copy of a fact is allowed only if a test named beside it diffs it against the first. No generator required and none mandated. One paragraph rather than a register under docs/, because a register is itself a second copy and would need its own guard. Enforcement is nothing new, just the existing guards plus a reviewer noticing.
  • The review ritual (A post-burst review ritual #323): architecture reviews are chartered as wayfinder maps when the reviewer judges enough has changed, never as a per-PR gate. The every-time mechanism is the fresh-context adversarial review of each PR by an agent that did not write it.

Checks

test_agents_doc.py, test_docs_prose.py, test_public_api_snapshots_doc.py, test_docs_links.py: 99 passed. The reworded paragraph keeps the ### The public-API snapshots heading, the scripts/public-api-snapshots.sh mention, and the canonical / #352 phrases those guards match on, and adds no em or en dash to docs/.

Closes #431.

🤖 Generated with Claude Code

Summary by Sourcery

Clarify public API snapshot validation and record the project’s standing rules for duplicated facts and review practices.

Bug Fixes:

  • Correct the public API snapshot documentation to distinguish partition errors caught locally from ordering errors caught by CI.
  • Document that hand-edited snapshots remain provisional until the public-api CI job validates them.

Enhancements:

  • Record standing guidance for testing second hand-maintained copies of facts.
  • Document the policy for architecture reviews and fresh-context adversarial PR reviews.

Documentation:

  • Clarify the validation workflow and limitations for hand-edited public API snapshots.
  • Add persistent contributor guidance for duplicate facts and review practices.

blooop added 2 commits August 29, 2026 18:01
The snapshots section told a contributor that a hand-edited snapshot
"fails in the Rust suite rather than in review". It does not. The Rust
tests hold the partition, and ordering is not a partition property, so
the misordered file on #427 passed 4/4 locally and was rejected by CI's
public-api job three hours later.

Say which half is caught where, and that a hand-edit is provisional
until CI agrees. Closes #431.
Two decisions from the 2026-08 review that were resolved on the tickets
and never written down. #319: a second hand-maintained copy of a fact
needs a diff test named beside it, no generator required, enforced by the
guards that already exist plus review attention. #323: architecture
reviews are chartered as wayfinder maps when the reviewer judges enough
has changed, and the every-time mechanism is the fresh-context
adversarial review of each PR by an agent that did not write it.

CLAUDE.md is a symlink to AGENTS.md, so the section lands there.

Refs #319, #321, #323.
@sourcery-ai

sourcery-ai Bot commented Aug 29, 2026

Copy link
Copy Markdown

Reviewer's Guide

Corrects the public API snapshot documentation to accurately separate local partition checks from CI ordering validation, and records resolved repository practices for second-copy safeguards and review responsibilities in the standing rules shared through CLAUDE.md.

Sequence diagram for fresh-context PR review

sequenceDiagram
    participant Author
    participant PR
    participant Reviewer as FreshContextAgent
    Author->>PR: Submit PR
    PR->>Reviewer: Request adversarial review
    Reviewer->>PR: Review without author context
    Reviewer-->>Author: Report defects or approve
    opt Enough architecture has changed
        Reviewer->>PR: Charter wayfinder map review
    end
Loading

Flow diagram for public API snapshot validation

flowchart LR
    Edit[Hand-edit snapshot] --> Local[public_api_snapshots.rs partition checks]
    Local -->|wrong tier| Fail[Local Rust suite fails]
    Local -->|correct tier| CI[CI public-api job regenerates and diffs]
    CI -->|wrong ordering| Reject[CI rejects snapshot]
    CI -->|matches generated output| Accept[Snapshot accepted]
Loading

Flow diagram for second-copy safeguards

flowchart LR
    Fact[First copy of fact] --> Copy[Second hand-maintained copy]
    Copy --> Guard[Test named beside copy]
    Guard --> Diff[Diffs second copy against first]
    Diff -->|matches| Allowed[Copy allowed]
    Diff -->|drifts| Fix[Review identifies and fixes drift]
Loading

File-Level Changes

Change Details Files
Clarifies where public API snapshot mistakes are detected and establishes CI validation as the final authority for hand-edited snapshots.
  • Distinguish partition errors caught by the Rust test from ordering errors caught by the CI public-api job.
  • Explain that hand-editing is the only available devcontainer workflow and remains provisional until CI regeneration agrees.
  • Preserve the documentation structure and terminology required by existing documentation guards.
docs/development.md
Records durable repository rules for maintaining duplicate facts and conducting architecture and PR reviews.
  • Require a neighboring diff test for any second hand-maintained copy of a fact, without mandating generators or new enforcement mechanisms.
  • Define architecture reviews as discretionary wayfinder maps rather than per-PR gates.
  • Establish fresh-context adversarial review by a non-authoring agent as the every-PR review mechanism.
AGENTS.md

Assessment against linked issues

Issue Objective Addressed Explanation
#431 Correct the development documentation so it accurately explains that the Rust snapshot tests validate partitioning and API-path placement, while ordering and rendering are checked only by CI's public-api regeneration job.
#431 Warn contributors that hand-edited snapshots are provisional and must be confirmed by the CI public-api job, particularly because regeneration is unavailable in the devcontainer.

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 1 issue

Prompt for AI Agents
Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="AGENTS.md" line_range="260" />
<code_context>
+  because the charter month produced three reviews unprompted and the trigger was
+  never the missing part. The mechanism that does run every time is smaller: the
+  fresh-context adversarial review of each PR by an agent that did not write it,
+  which is where the last three real defects were caught — #427's layering
+  violation, #415's four-hole guard, #428's dropped `Absent`.
</code_context>
<issue_to_address>
**nitpick:** The review-ritual paragraph misidentifies #427's defect as a layering violation, while this change's own rationale identifies #427 as the misordered `public-api.rest.txt` snapshot that passed local tests and failed CI. This gives readers an incorrect example of the defects supposedly caught by fresh-context review.

**Suggested fix:** Replace "#427's layering violation" with the misordered public-API snapshot defect, or cite the issue that actually contained the layering violation.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread AGENTS.md
because the charter month produced three reviews unprompted and the trigger was
never the missing part. The mechanism that does run every time is smaller: the
fresh-context adversarial review of each PR by an agent that did not write it,
which is where the last three real defects were caught — #427's layering

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: The review-ritual paragraph misidentifies #427's defect as a layering violation, while this change's own rationale identifies #427 as the misordered public-api.rest.txt snapshot that passed local tests and failed CI. This gives readers an incorrect example of the defects supposedly caught by fresh-context review.

Suggested fix: Replace "#427's layering violation" with the misordered public-API snapshot defect, or cite the issue that actually contained the layering violation.

@blooop
blooop merged commit c89f7d7 into main Aug 29, 2026
15 checks passed
@blooop
blooop deleted the docs/431-honest-snapshot-sentence branch August 29, 2026 17:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

A hand-edited snapshot passes the Rust suite the docs say would catch it

1 participant