Skip to content

Vendored history.yaml still states the pre-#325 enforcement policy #358

Description

@realmarcin

Raised in review of #357, which made a history record required.

src/traitmech/schema/history.yaml carries two statements that #325 superseded:

  • line 9"One record per session per target, written once and never edited." No history/records entry for the 128-file #302 migration #325 re-scoped this: per target for hand curation, per migration for a bulk edit. Read literally it makes a 128-file migration owe 128 near-identical records.
  • lines 20–23"ENFORCEMENT IS DELIBERATELY SPLIT. Presence of a record is *advisory* — CI warns, it does not block, because a hard gate on provenance blocks legitimate work at inconvenient moments and trains people to route around it."

The second is now false, and it is verbatim the argument #325 refuted with measurement: of 134 commits that modified trait records, 2 added a history record. Nobody routed around the gate because there was no gate.

Why #357 did not just fix it

The file is vendored byte-identical from culturebotai-claw/shared/history/history.yaml. Editing the TraitMech copy would create drift from the canonical one, and nothing would detect it: src/traitmech/schema/history.yaml is not in scripts/check_vendored_sync.sh's checked set, and claw is private so this repo's CI cannot reach it to diff. A one-copy edit here is exactly the failure mode vendored-sync exists to prevent, and this file happens to sit outside its coverage — which is the gap #209 tracks.

history/README.md and .github/workflows/curation-history.yaml now carry the operative policy and note that the schema's prose is stale by design rather than neglect.

What to do

  1. Update the canonical copy in claw (shared/history/history.yaml), re-vendor into all four Mech repos.
  2. Consider adding history.yaml to check_vendored_sync.sh so the next divergence is caught — though that needs the hub-reachability question in vendored-sync.yaml is now a fourth de-facto shared file with no drift protection #209 answered first, since the canonical hub for this file is private.

Not urgent: the schema's structure is correct and validation works; only its prose disagrees with the enforced policy.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions