Skip to content

curating-context: pin .skills/context-counts-ok entries so per-doc runs stop reporting them (skills#279) #299

Description

@gregoryfoster

gregoryfoster/skills#279 shipped in 2e94a27 (curating-context 1.25). check-counts.sh honoured a PATH pin when matching an acknowledgement but ignored it when reporting stale entries, so a run against one file told you to prune entries judged for another.

State here

  • skills-vendor/gregoryfoster-skills is at b4f5cf0 (skill 1.24) — 5 commits behind.
  • .skills/context-counts-ok holds 4 entries, none pinned. All four read as AGENTS.md text (watcher publishes four streams…, Records are JSON with a four-key floor, Two env files load in order, Three unit-only opt-ins…).
  • This repo curates more than one surface: 97 markdown docs under docs/, 13 PATH-pinned entries in .skills/context-loss-ok and 13 in .skills/context-seams-ok. So per-doc --file runs do happen here, and those are the runs that misreported.

What the old and new reports do

On a check-counts.sh --file docs/<any>.md run, the four entries matched nothing, because their text is in AGENTS.md. The old report listed them under "matched nothing — the text each warranted has changed or gone; re-judge and prune", which was simply false.

After the bump they are reported as ambiguous instead: "matched nothing AND name text that is not in docs/.md … the text was re-worded (re-judge and prune), or the entry was judged for another file (scope it with PATH :: WARRANT :: CONTENT). Do not prune on this run alone." That is safe, and still noise on every per-doc run.

Suggested action

  1. Bump skills-vendor/gregoryfoster-skills to at least 2e94a27 (managing-skills, "Updating a skill repo").
  2. Prefix each of the four entries with AGENTS.md :: , giving AGENTS.md :: gated :: watcher publishes four streams and consumes two and so on. Per-doc runs then report them as scoped to another target — not consulted, and drop out of the report entirely.

Pinning buys more than quiet. Unpinned, an entry whose text really has gone stale can only ever be reported ambiguous, because the run cannot tell a re-worded line from an entry judged elsewhere. Pinned, the same entry is reported stale with "re-judge and prune" — the expiry the acknowledgement grammar promises. That is the whole point of #251, which this fix carries over to counts.

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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions