Skip to content

Converge Blog with the hub baseline (7 findings) #38

Description

@ptr727

Generated from the hub audit of Blog (hugo, source-only). Run stamp audit run 2026-08-05T22:57:15Z | hub 0d42a1c, against @ main@2b132e4 (the format AUDIT.md section 8 says a derived artifact quotes). Regenerate with spec/audit.py --issue Blog. Findings are a point-in-time snapshot - re-run the audit before acting. This lists what the audit mechanically detects. No check belonging to a project type in spec/project-types.json is run here, and the cross-cutting dimensions are covered only in part, so the full letter and intent verdict lives in AUDIT.md section 4.

Converge

Divergences from the hub canonical. A verbatim: file or section re-vendors the current hub copy byte-for-byte (a section re-vendors just that one ## heading block). An interface: item must honor the named workflow contract. A stale-but-present copy is re-vendored. A genuinely repo-specific difference is judged by meaning per AUDIT.md.

  • verbatim: GOVERNANCE.md section 'Branching Model' matches a past hub revision, not the current canonical - the base advanced, re-vendor it
  • verbatim: GOVERNANCE.md section 'Communicating with the User' matches a past hub revision, not the current canonical - the base advanced, re-vendor it
  • verbatim: GOVERNANCE.md section 'Documentation Style Conventions' matches a past hub revision, not the current canonical - the base advanced, re-vendor it
  • verbatim: GOVERNANCE.md section 'Release Model' matches a past hub revision, not the current canonical - the base advanced, re-vendor it
  • verbatim: GOVERNANCE.md section 'Repository Boundaries and Write Safety' matches a past hub revision, not the current canonical - the base advanced, re-vendor it
  • verbatim: GOVERNANCE.md section 'Repository Details' matches a past hub revision, not the current canonical - the base advanced, re-vendor it
  • verbatim: .markdownlint-cli2.jsonc matches a past hub revision, not the current canonical - the base advanced, re-vendor it

Sequence the Two Release-Model Sections Together

Do not re-vendor Release Model without Branching Model in the same change. The issue-closing-keyword rule (Closes #N goes on the promotion PR, not the feature PR) moved out of Release Model into Branching Model upstream. This repo still carries it in the old location. Taking the new Release Model alone deletes the rule rather than leaving it stale, and the audit would then report nothing, because both sections would match their current canonical.

What Changed Upstream, So the Diffs Read as Intended

Three of the seven differ only in the capitalization of the word Markdown in prose. No rule changed in those.

The other four are rule additions this repo states in an older form:

SectionWhat it gains
Repository Boundaries and Write SafetyA refused write is reported, never re-shaped, and conversational authorization does not lift a refusal by the agent harness
Communicating with the UserThe form of a reference follows the surface it is read on, plus work blocked on the user is raised as a direct interactive prompt whose options are the actions themselves
Release ModelThe filesystem-deploy leaf, which describes this repository's own deploy shape, including the retention rule
Branching ModelThe issue-closing-keyword rule, moved in from Release Model (see above)

One Finding You Will See That Is Not Yours

If you re-run the audit before the hub merges its pending fix, you will also get:

DRIFT carried: AGENTS.md references the template repo by name or link

Ignore it, and do not act on it. It is a hub defect, not a deviation in this repository. The check scanned the whole file for the hub's name with no exemption for the byte-locked Fleet Bootstrap section, whose first sentence must name the hub because stating where the canonical rules live is that section's entire function. This repository's copy is byte-identical to the hub's own, so the finding was unclearable: the only way to satisfy it was to edit a section the verbatim check then flags.

The fix is open upstream and the run stamp above is taken from it, which is why the finding is absent from this list. Once it merges, a re-run drops it on its own.

Scope

One focused PR for this class, per AUDIT.md section 10. The prose findings are filed separately and are not part of this one.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions