Skip to content

prose_lint: the hub's own docs, spec, and catalog do not pass the gate it ships #519

Description

@ptr727

Summary

scripts/prose_lint.py is enforced on downstream repos, but the hub's own tree does not pass it. Running the gate from a clean hub clone at 69688ec:

python3 scripts/prose_lint.py .
668 violation(s)

Excluding the generated reports/ tree, 119 violations remain in hand-authored content:

file violations
docs/devcontainer.md 22
spec/type-model.md 17
docs/ssh-signing.md 17
catalog/snippets/vscode/README.md 13
catalog/snippets/workflows/README.md 9
spec/fidelity-model.md 8
spec/scope-model.md 7
docs/repo-config-carry.md 7
catalog/README.md 6
docs/token-cost.md 5
host-setup/agent-safety/claude-md-safety.md 3
catalog/snippets/husky/README.md 3
catalog/snippets/configs/docker-hub-readme.md 2

The governance files themselves are clean, so this is not a carry problem. GOVERNANCE.md, AGENTS.md, CODESTYLE.md, WORKFLOW.md, AUDIT.md, repo-config/README.md, and .github/copilot-instructions.md all report zero. The gap is in the surrounding documentation and the spec models.

Why it matters

Two of the affected files are the spec models a downstream agent reads to decide what is carried and how faithfully: spec/fidelity-model.md and spec/scope-model.md. An agent sent to those documents to resolve a conformance question reads prose that the same repository's gate rejects, which undercuts the rule while teaching it.

catalog/snippets/** is the more direct risk. Those are the snippets downstream repos copy, so a non-conformant snippet seeds a violation into every repo that adopts it, and the downstream repo then gets flagged for content it was handed.

Questions

  1. Is reports/** intended to be exempt? It is generated output, so a documented exclusion in the gate (rather than a standing backlog of 549) would make the hub's own result meaningful.
  2. Should catalog/snippets/** be treated as higher priority than the rest, given the seeding effect above?

Context

Found while bringing ptr727/PhotoCleaner to spec ahead of going public (ptr727/PhotoCleaner#35). That repo's own carried files were stale rather than wrong: the hub's copies are clean and PhotoCleaner's were behind, which is a separate catch-up on our side and not a hub defect.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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