Skip to content

feat(work-items): extract shared self-observation filing contract (#540) - #762

Merged
kyle-sexton merged 8 commits into
mainfrom
fix/540-work-items-shared-dogfood-skill
Jul 21, 2026
Merged

feat(work-items): extract shared self-observation filing contract (#540)#762
kyle-sexton merged 8 commits into
mainfrom
fix/540-work-items-shared-dogfood-skill

Conversation

@kyle-sexton

Copy link
Copy Markdown
Contributor

Summary

The cross-lane self-observation filing rule — file a problem you will not fix in-cycle: dedupe → categorize → fixed shape → needs-triage — is cross-lane-identical. The v4 loop-prompt absorption umbrellas (#477 babysit, #478 triage, #479 work) each absorb lane-specific rules into their own skill; absorbing this shared block three times would manufacture three drift-prone copies of one contract. This extracts it into a single in-repo surface the lanes reference instead.

Fix

  • New plugins/work-items/reference/dogfood-filing.md — the single source of truth for the self-observation filing contract. It composes the existing mechanics by pointer (pointer-not-copy): the Search items dedupe read and the body template track add already owns, the create-item seam write, and the needs-triage status label. It restates none of them; it adds only the self-observation policy — when to file vs the tracker-seam.md "Default = fix, not file" posture, the mechanical-vs-model split, autonomous-lane authorization, and the AI disclaimer.
  • Wired the three in-repo filing sites to reference the contract at their filing point: work's post-green deferred-finding follow-up, triage's follow-up-work creation, and scan-todos's "file a work item" branch.
  • Follows the repo's established cross-lane-shared-block precedent (reference/permission-preflight.md: a shared reference doc consumed by multiple lanes, with its script owned by one skill), not a new user-invocable skill.

Veto points before merge (decision-defaulted per the triage brief)

  1. Shape: reference doc, not a user-invocable skill. The triage brief said "shared skill (naming open)"; the repo's actual precedent for a cross-lane shared contract is a reference/ doc (permission-preflight.md), which is reversible and does not ship a hard-to-unship slash command. Chose the precedent.
  2. No new script. The brief called the mechanical core "script-shaped." It is already scripted — the seam create-item + bound-adapter Search items + track add body template. A standalone wrapper would fork the very template and search mechanics this doc single-sources, so the doc references them instead.
  3. Authoritative wording. The full rule text lives in the external v4 standing-loop prompts (babysit source-control(babysit-prs): absorb v4 loop-prompt operating rules into the skill #477 is not yet absorbed). This doc is the in-repo surface those prompts reconcile against; the exact filing-shape phrasing should be reconciled with the external prompts when source-control(babysit-prs): absorb v4 loop-prompt operating rules into the skill #477 lands.

Verification

Ran locally against origin/main:

  • check-changed-skills.sh — 3 skills PASS, 0 errors; all base-ref trigger phrases preserved; broken-ref check confirms the new reference/dogfood-filing.md links resolve.
  • check-skill-portability.sh — no coupling tokens.
  • check-changelog-parity.sh --check-bump — version bump + CHANGELOG entry present (0.17.1 → 0.18.0).
  • validate-plugins.sh — all manifests + catalog validate.
  • markdownlint-cli2 — 0 errors on the new doc and CHANGELOG.

Closes #540

Related

The cross-lane "file what you will not fix" rule (dedupe -> categorize ->
fixed shape -> needs-triage) was slated to be absorbed privately into each
lane's skill, manufacturing three drift-prone copies of one contract.

Extract it into one shared reference surface, reference/dogfood-filing.md,
that composes the existing mechanics by pointer (the Search-items dedupe read
and body template track add owns, the create-item seam write, the needs-triage
status label) and adds only the self-observation policy. No new script: the
mechanical core is already the seam + adapter + track add machinery, so the
doc points at it rather than forking the template and search mechanics.

Wire the three in-repo filing sites (work post-green deferred finding, triage
follow-up creation, scan-todos file-a-work-item) to reference the contract
instead of leaving the sequence implicit.

Co-Authored-By: Claude Opus <noreply@anthropic.com>
@kyle-sexton kyle-sexton added the automated Opened by automation. label Jul 20, 2026
@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 2m 49s —— View job


PR Review: feat(work-items): extract shared self-observation filing contract (#540)

  • Gather context and understand the request
  • Read changed files and diff
  • Review architecture and design decisions
  • Review content correctness (links, references, contracts)
  • Check alignment with CLAUDE.md / PLUGIN-PHILOSOPHY.md
  • Post review findings

Summary

This is a clean, well-executed extraction with no blocking issues. The design is sound and follows the established precedent. Notes below are observations, not objections.


Architecture: pointer-not-copy is correct here

The choice to use a reference/ doc rather than a user-invocable skill is the right call. The permission-preflight.md precedent is directly applicable — a cross-lane shared contract that has no slash-command surface, lives in reference/, and is consumed by multiple skills pointing at it. The reasoning in the PR description is well-grounded.

The "no new script" decision also holds: the mechanical core (dedupe search, template body, create-item write) is already the seam + adapter + track add machinery. Adding a wrapper would fork the very template this doc exists to single-source.


Link resolution: all paths verified

All relative links from dogfood-filing.md resolve correctly:

Link in doc Resolves to
tracker-seam.md reference/tracker-seam.md
../skills/work/SKILL.md skills/work/SKILL.md
../skills/track/actions/add.md skills/track/actions/add.md
label-taxonomy.md reference/label-taxonomy.md
../skills/triage/SKILL.md skills/triage/SKILL.md

The ${CLAUDE_PLUGIN_ROOT}/reference/dogfood-filing.md paths in the three skill files are consistent with how other plugin-root-relative links are expressed throughout the skill files.


Wiring sites: correct placement

Each of the three wiring sites is placed exactly where the filing decision is made:


One observation worth noting (not blocking)

triage wiring scope is clear but subtle. The sentence at triage/SKILL.md:140 reads:

"Item creation, when triage spawns follow-up work, goes through the seam create-item verb... and follows the shared self-observation contract"

The qualifying clause "when triage spawns follow-up work" correctly scopes this away from triage's primary outcome writes (briefing and labeling the item being triaged) — those don't go through the self-observation contract and shouldn't. A reader who skims Item creation... without the qualifier might misread it as applying to all item creation in triage, including the briefed-item outcomes from step 5. The current phrasing is defensible, but a small clarification like "Item creation for incidental follow-up work" would make the scope unmissable. Not a blocker — just flagging for future readability.


Policy content: accurate

  • "Fix, not file" default (tracker-seam.md alignment) is correctly stated and cited ✓
  • Authorization model (interactive draft-then-ask vs autonomous lane's standing rules) matches the existing triage/SKILL.md "Direction gate" exactly ✓
  • The four-beat sequence (dedupe → categorize → file via track add → label needs-triage) is internally consistent and correctly marks the mechanical vs judgment split ✓
  • #506 placeholder for eventual auto-label ownership is honest ✓
  • Reconciliation note about #477 (babysit-prs still absorbing) is an appropriate forward-reference, not a gap ✓

Version bump: correct

0.17.1 → 0.18.0 is the right semver call — a new file added and existing skills updated constitutes a minor feature bump. CHANGELOG entry is thorough and matches what changed.


Verdict: ready to merge. The extraction is clean, the wiring is precise, and the design avoids the drift-prone copy problem it targets.

@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 1m 12s —— View job


Security Review — PR #762

  • Gather PR diff and changed files
  • Read new reference doc (dogfood-filing.md)
  • Read modified skill files
  • Analyze for security issues
  • Post findings

No security issues found.

This PR is entirely documentation and configuration — one new markdown reference doc, three single-line wiring edits in existing SKILL.md files, a version bump in plugin.json, and a CHANGELOG entry. I reviewed against every relevant attack surface:

Injection (command, path, template). The three SKILL.md edits each add a ${CLAUDE_PLUGIN_ROOT}/reference/dogfood-filing.md reference. ${CLAUDE_PLUGIN_ROOT} is a controlled Claude Code plugin variable resolved by the runtime from the plugin's installation directory, not from user input. No shell evaluation, no run: blocks, no path traversal risk.

GitHub Actions. No .github/workflows/ files were modified. No pull_request_target, workflow_run, or permissions: changes. No script injection surface via github context.

Secrets / credentials / tokens. None present or referenced in any changed file.

Supply chain / dependency pins. No new package dependencies, action pins, or external MCP connections introduced.

Autonomous authorization model (the policy itself, dogfood-filing.md lines 61–69). The doc grants autonomous lanes permission to create tracker items without per-item confirmation, gated on "standing rules already authorize tracker mutations." The scope is narrow (tracker item creation / comments only), requires an explicit pre-existing authorization grant, and mandates an AI disclaimer on all autonomous output. This is a documentation of an existing pattern, not a new capability or an authorization widening.

Information disclosure. Internal issue numbers (#477, #506) and plugin-relative file paths are referenced. These are non-sensitive project-management identifiers with no secret value.

Nothing in this changeset introduces a new executable path, external trust dependency, or policy that expands the plugin's security boundary.

@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 1m 55s —— View job


PR Review: feat(work-items): extract shared self-observation filing contract (#540)

  • Gather context and understand the request
  • Read changed files and diff
  • Review architecture and design decisions
  • Review content correctness (links, references, contracts)
  • Check alignment with CLAUDE.md / PLUGIN-PHILOSOPHY.md
  • Post review findings

Summary

This is a clean extraction with no blocking issues. The design is correct and precedent-consistent. The notes below are observations, not objections.


Architecture: correct approach

The reference/ doc shape matches the established permission-preflight.md precedent — a cross-lane shared contract with no slash-command surface, consumed via pointer by multiple skills. The "no new script" decision is also sound: the mechanical core (dedupe search, track add body template, create-item write) already exists in the seam + adapter machinery. A standalone wrapper would fork the very template this doc exists to single-source.


Link and anchor verification: all resolve

All relative links from dogfood-filing.md were verified against the current files:

Reference Target Status
tracker-seam.md "Default = fix, not file" reference/tracker-seam.md line 92
add.md "Duplicate check" skills/track/actions/add.md line 36
add.md "Authorization gate" skills/track/actions/add.md line 32
add.md "Build body" skills/track/actions/add.md line 44
add.md "Create the item" skills/track/actions/add.md line 74
triage/SKILL.md "Recommend category + state" skills/triage/SKILL.md line 90
triage/SKILL.md "Attention view" skills/triage/SKILL.md line 70
triage/SKILL.md "Direction gate" skills/triage/SKILL.md line 98
triage/SKILL.md "AI disclaimer" skills/triage/SKILL.md line 162
label-taxonomy.md (status axis) reference/label-taxonomy.md
work/SKILL.md "Post-green review pass" skills/work/SKILL.md line 189

The ${CLAUDE_PLUGIN_ROOT}/reference/dogfood-filing.md paths in the three wiring sites are consistent with the plugin-root-relative convention used elsewhere in the skill files.


Wiring sites: correct placement

Each wiring edit inserts the reference exactly at the decision point:


One readability observation (not blocking)

triage/SKILL.md:140 now reads:

"Item creation, when triage spawns follow-up work, goes through the seam create-item verb... and follows the shared self-observation contract"

The qualifying clause "when triage spawns follow-up work" correctly scopes this away from triage's primary outcome writes (briefing and labeling the item under review) — those don't go through the self-observation contract and shouldn't. A reader skimming from "Item creation..." without the qualifier might misread it as applying to all item creation in triage, including step 5 outcome writes. The current phrasing is defensible; "Item creation for incidental follow-up work" would make the scope unmissable at a glance. Not a blocker.


Policy content: accurate

  • "Fix, not file" default and the narrow-exception framing align exactly with tracker-seam.md line 92 ✓
  • The four-beat sequence (dedupe → categorize → file via track addneeds-triage) is internally consistent and correctly partitions mechanical vs. judgment steps ✓
  • Authorization model (interactive draft-and-ask vs. autonomous standing-rules) matches triage/SKILL.md Direction gate exactly ✓
  • #506 placeholder for eventual auto-label ownership is honest about current state ✓
  • Reconciliation note for #477 (babysit not yet absorbed) is an appropriate forward-reference ✓

Version bump and CHANGELOG

0.17.1 → 0.18.0 is the correct semver call — a new reference file added plus three skill updates constitutes a minor feature bump. CHANGELOG entry is thorough and matches what changed.


Verdict: ready to merge. The extraction is clean, the wiring is precise, all references resolve, and the design correctly avoids the drift-prone copy problem it targets.

@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 1m 5s —— View job


Security Review — PR #762

  • Gather PR diff and changed files
  • Read new reference doc (dogfood-filing.md)
  • Read modified skill files
  • Analyze for security issues
  • Post findings

No security issues found.

This PR is entirely documentation and configuration: one new markdown reference doc, three single-line wiring edits in existing SKILL.md files, a version bump in plugin.json, and a CHANGELOG entry. I reviewed against every relevant attack surface.

Injection (command, path, template). The three SKILL.md edits each add a ${CLAUDE_PLUGIN_ROOT}/reference/dogfood-filing.md reference. ${CLAUDE_PLUGIN_ROOT} is a controlled Claude Code plugin variable resolved by the runtime from the plugin's installation directory — it is not derived from user input and has no shell evaluation context. No run: blocks, no path traversal risk.

Autonomous authorization model (dogfood-filing.md lines 66–74). The doc states autonomous lanes with standing rules authorizing tracker mutations may create items without per-item confirmation. This is a documentation of an existing pattern already expressed in triage/SKILL.md's direction gate — not a new authorization grant or a widening of the permission boundary. The scope is narrow (tracker item creation and comments only), requires an explicit pre-existing authorization grant in the lane's standing rules, and mandates an AI disclaimer on all autonomous output.

GitHub Actions. No .github/workflows/ files modified. No pull_request_target, workflow_run, or permissions: changes. No script injection surface.

Secrets / credentials / tokens. None present or referenced in any changed file.

Supply chain / dependency pins. No new package dependencies, action pins, or external MCP connections introduced.

Information disclosure. Internal issue numbers (#477, #506, #573) and plugin-relative file paths are referenced. These are non-sensitive project-management identifiers with no secret value.

Nothing in this changeset introduces a new executable path, external trust dependency, or policy that expands the plugin's security boundary.

@chatgpt-codex-connector chatgpt-codex-connector 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.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1859d9c118

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread plugins/work-items/reference/dogfood-filing.md
Move the "when triage spawns follow-up work" qualifier to the front of the
sentence so a reader skimming from "Item creation..." cannot misread the
shared self-observation contract as applying to triage's primary outcome
writes. Addresses a readability note from the PR review bots; no semantic
change.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 2m 23s —— View job


PR Review: feat(work-items): extract shared self-observation filing contract (#540)

  • Gather context and understand the request
  • Read changed files and diff (latest commit)
  • Analyze Codex P2 finding on frontier exclusion
  • Review architecture and content correctness
  • Post review findings

Latest commit (6e4c2d2)

The new commit — docs(work-items): front-load scope condition on triage filing sentence — directly addresses the readability observation from prior reviews. The sentence in triage/SKILL.md:140 changed from:

"Item creation, when triage spawns follow-up work, goes through the seam create-item verb…"

to:

"When triage spawns follow-up work, item creation goes through the seam create-item verb…"

Front-loading the qualifying clause makes the scope unmissable. This is the right fix and the exact wording suggested in the prior review.


Codex P2 finding — frontier exclusion analysis

The Codex review flagged that a self-filed item labeled only status:needs-triage can appear on the work frontier and be claimed by /work-items:work in autonomous deployments where the two lanes run independently.

The mechanism is real. From CONTRACT.md:66-77:

list-frontier filters: state == open AND blocked_by_count == 0 AND no assignee AND not a container. With --autonomous, items labeled needs-human are additionally excluded.

A self-observation item filed per this contract is open, unassigned, unblocked, and carries status:needs-triage — not needs-human. It passes all frontier filters. Tier 3 of /work-items:work ("highest-impact non-recurring unassigned items — the remaining frontier") has no mechanical check that skips needs-triage items; the selection is model-judgment-driven, which is not a reliable gate.

However, this gap is pre-existing and not introduced by this PR. Self-observation items were already being filed with status:needs-triage by each lane before this extraction — the same gap existed wherever those filings happened. This PR extracts the shared contract without widening the window. The fix (excluding needs-triage from list-frontier --autonomous, or adding a core-side filter in the work skill's tier 2–3 pass) belongs in the seam contract or the work skill, not in this reference doc.

What this PR could do (not required to merge): dogfood-filing.md step 4 could note that until the seam excludes needs-triage from list-frontier --autonomous, this label is necessary-but-not-sufficient to prevent raw-intake pickup by /work-items:work. That would make the gap visible at the filing site and point toward where the fix lands. Worth a follow-up issue rather than a merge blocker here.


Prior review observations: all addressed

Both the P1 architecture verdict and the P2 readability note from prior Claude reviews are now resolved:

Prior observation Status
Triage sentence scope "unmissable" wording Fixed in 6e4c2d2
All link paths resolve Unchanged, still verified ✓
Version bump 0.17.1 → 0.18.0 Correct ✓
Policy content accuracy (fix-not-file, auth model, four-beat sequence) Unchanged, still correct ✓

Verdict: ready to merge. The latest commit correctly resolves the outstanding readability observation. The Codex P2 finding describes a pre-existing seam-level gap not caused by this PR; it warrants a follow-up issue against the seam contract or work skill rather than blocking this extraction.

@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 2m 0s —— View job


Security Review — PR #762

  • Gather PR diff
  • Read changed files
  • Analyze for security issues
  • Post findings

No security issues found.

This PR is entirely documentation and configuration: one new markdown reference doc (dogfood-filing.md, 81 lines), three single-line wiring edits in existing SKILL.md files (one later adjusted to a readability tweak), a version bump in plugin.json, and a CHANGELOG entry. I reviewed against every relevant attack surface.

Injection (command, path, template). The three SKILL.md wiring edits each add a ${CLAUDE_PLUGIN_ROOT}/reference/dogfood-filing.md reference. ${CLAUDE_PLUGIN_ROOT} is a Claude Code plugin template variable resolved by the runtime from the plugin's installation directory — it is not derived from user input and carries no shell evaluation context. These references appear in instruction-text markdown, not in run: blocks, scripts, or any executable surface. No command injection, path traversal, or template injection risk.

Autonomous authorization model (dogfood-filing.md lines 66–74). The doc states that autonomous lanes with standing rules already authorizing tracker mutations may create items without per-item confirmation. This is a documentation of behavior that already exists in triage/SKILL.md's Direction gate — not a new authorization grant or permission widening. The scope is narrow (tracker item creation and comments only), requires an explicit pre-existing authorization grant in the lane's standing rules, and mandates an AI disclaimer on all autonomous output.

GitHub Actions. No .github/workflows/ files were modified. No pull_request_target, workflow_run, or permissions: changes. No run: block with github context interpolation.

Secrets / credentials / tokens. None present or referenced in any changed file.

Supply chain / dependency pins. No new package dependencies, action pins, or external MCP connections introduced.

Information disclosure. Internal issue numbers (#477, #506, #573) and plugin-relative file paths are referenced — non-sensitive project-management identifiers with no secret value.

Re: Codex P2 comment on frontier exclusion. The concern is valid as a design observation — needs-triage items filed by an autonomous lane could be selectable by a concurrent autonomous work loop before triage evaluates them. However, this is a pre-existing design characteristic of the frontier filter, not introduced by this PR. The three wiring sites already filed items this way before this PR centralized the documentation into dogfood-filing.md; the frontier filter semantics are unchanged. Addressing it would require a change to the frontier filter or a new exclusion label, which is out of scope here.

Nothing in this changeset introduces a new executable path, external trust dependency, or policy that expands the plugin's security boundary.

@kyle-sexton

Copy link
Copy Markdown
Contributor Author

Re: PR review (@claude[bot])

# Finding Classification Evidence Reacted
1 triage/SKILL.md:140 — "Item creation, when triage spawns follow-up work, …" could be misread as scoping all triage item creation to the self-observation contract VALID — fixed Front-loaded the scope condition 👍
2 Otherwise clean; links/anchors/wiring/policy/version all verified; "ready to merge" Acknowledged — no action Verdict noted 👍

Fixed in 6e4c2d20. Moved the qualifier to the front of the sentence so it can't be skimmed past — now reads "When triage spawns follow-up work, item creation goes through the seam create-item verb … and follows the shared self-observation contract." Kept the exact scoping meaning (deliberately did not adopt "incidental", which would shift the connotation); zero semantic change.

Separately, the Codex P2 on dogfood-filing.md:52 (raw needs-triage filings entering the --autonomous frontier before triage) is confirmed VALID but deferred — the fix is a list-frontier --autonomous semantics change in the seam, out of scope for this doc-only PR. Classified in that thread; recommending a follow-up issue.

@chatgpt-codex-connector chatgpt-codex-connector 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.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6e4c2d2053

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread plugins/work-items/reference/dogfood-filing.md Outdated
@kyle-sexton

Copy link
Copy Markdown
Contributor Author

Codex's list-frontier gap finding (comment 3617886236) is tracked in #764 rather than left as a bare deferred reply — filed by the orchestrator on the worker's recommendation.

…fic wording

Non-triage lanes routed to triage's "AI disclaimer" section were told to reuse
its literal "during triage" wording, mislabeling the provenance phase of items
filed during work / scan-todos / babysit cycles. Instruct each lane to name its
own lane and treat triage's section as the canonical form only; track the
lane-neutral disclaimer SSOT that collapses this to one pointer in #768.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 1m 16s —— View job


PR Review: feat(work-items): extract shared self-observation filing contract (#540)

  • Gather context and understand the request
  • Read latest diff (commit c1df8d1)
  • Review AI disclaimer fix in dogfood-filing.md
  • Verify all outstanding findings are addressed
  • Post review findings

Latest commit (c1df8d1) — AI disclaimer provenance fix

This commit addresses the Codex P2 finding on triage-specific disclaimer wording. The original text at dogfood-filing.md lines 73–74 pointed non-triage lanes at triage's "AI disclaimer" section without qualification — meaning work, scan-todos, and babysit filings would all carry triage's literal This was generated by AI during triage. and misidentify their provenance phase.

The fix at dogfood-filing.md lines 73–77:

"triage's … 'AI disclaimer' section is the canonical form, but a non-triage lane names its own lane rather than inheriting triage's literal during triage wording, so the provenance phase stays accurate. A lane-neutral disclaimer SSOT that collapses this to a single pointer is tracked in #768."

Assessment: correct. Verified against triage/SKILL.md:162–166 — triage's section does contain This was generated by AI during triage. so the fix correctly guards against that literal being inherited. The two-part resolution (immediate: name your own lane; eventual: #768 SSOT) is the right incremental shape — it closes the audit-trail gap now without waiting for the full consolidation.


All outstanding findings resolved

Finding Source Status
Triage sentence scope unmissable Claude review Fixed in 6e4c2d2
Frontier exclusion gap (needs-triage on autonomous frontier) Codex P2 Deferred to #764 — pre-existing seam gap, out of scope for this doc-only PR ✓
AI disclaimer names wrong lane for non-triage filings Codex P2 Fixed in c1df8d1

Verdict: ready to merge. All three findings from prior rounds are addressed. The extraction is clean, wiring is precise, all references resolve, the disclaimer fix closes the audit-trail gap, and the two deferred items (#764 frontier semantics, #768 disclaimer SSOT) are correctly scoped to their own follow-up issues.

@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 1m 21s —— View job


Security Review — PR #762

  • Gather PR diff and changed files
  • Read new reference doc (dogfood-filing.md)
  • Read modified skill files
  • Analyze authorization model and policy surfaces
  • Post findings

No security issues found.

This PR consists of one new markdown reference doc (84 lines), three single-line wiring edits in existing SKILL.md files, a version bump in plugin.json, and a CHANGELOG entry. I reviewed against every relevant attack surface.

Injection (command, path, template). The three SKILL.md wiring edits each add a ${CLAUDE_PLUGIN_ROOT}/reference/dogfood-filing.md reference. ${CLAUDE_PLUGIN_ROOT} is a controlled Claude Code plugin variable resolved from the plugin's installation directory by the runtime — it is not derived from user input and carries no shell evaluation context. These references appear in instruction-text markdown, not in run: blocks, scripts, or any executable surface. No command injection, path traversal, or template injection risk.

Autonomous authorization model (dogfood-filing.md lines 68–77). The doc states that autonomous lanes whose standing rules already authorize tracker mutations may create items without per-item confirmation. This documents behavior already present in triage/SKILL.md's Direction gate — it is not a new authorization grant or permission widening. Scope is narrow (tracker item creation and comments only), requires an explicit pre-existing authorization grant in the lane's standing rules, and mandates an AI disclaimer naming the specific originating lane rather than inheriting triage-specific wording (HEAD commit c1df8d1 correctly guards this).

AI disclaimer accuracy. The Codex finding from the prior review round (non-triage lanes inheriting triage's literal during triage wording) is fully addressed in commit c1df8d1: the contract now explicitly requires a non-triage lane to name its own lane rather than inheriting triage's wording, so autonomous items correctly identify their provenance. A future consolidation into a single SSOT is tracked in #768.

GitHub Actions. No .github/workflows/ files modified. No pull_request_target, workflow_run, or permissions: changes. No run: block with github context interpolation.

Secrets / credentials / tokens. None present or referenced in any changed file.

Supply chain / dependency pins. No new package dependencies, action pins, or external MCP connections introduced.

Information disclosure. Internal issue numbers (#477, #506, #573, #768) and plugin-relative file paths are referenced — non-sensitive project-management identifiers with no secret value.

Re: Codex P2 frontier exclusion finding. The concern (raw needs-triage items being selectable by an autonomous /work-items:work loop before triage vets them) is a real design characteristic of the list-frontier --autonomous filter. As confirmed in kyle-sexton's classification comment and tracked in #764, this is a pre-existing gap in the seam contract, not introduced by this PR. Addressing it requires a behavioral change to list-frontier --autonomous semantics (seam/CONTRACT.md) or an agent-ready-required positive gate in the work skill — both out of scope for this doc-only extraction.

Nothing in this changeset introduces a new executable path, external trust dependency, or policy that expands the plugin's security boundary.

@chatgpt-codex-connector chatgpt-codex-connector 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.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c1df8d1468

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread plugins/work-items/skills/triage/SKILL.md Outdated
…tions only

The new pointer to the shared self-observation contract read as if every
triage-spawned follow-up gets needs-triage, including work triage has already
scoped and the item under evaluation. Clarify that the contract (-> needs-triage)
governs only a fresh, orthogonal problem triage surfaces but will not fix this
pass: that new item is genuinely raw, while the evaluated item's raw marker is
cleared by the closing invariant and already-decided follow-up is routed through
the outcome labels — so neither loops back into raw intake.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 1m 59s —— View job


PR Review: feat(work-items): extract shared self-observation filing contract (#540)

  • Gather context and understand the request
  • Read latest diff (commit cbcbf81)
  • Review fix for Codex P2: triage follow-up filing scoped to fresh self-observations
  • Verify all outstanding findings resolved
  • Post review findings

Latest commit (cbcbf81) — triage follow-up scope fix

This commit addresses the Codex P2 finding from the previous round: triage-spawned follow-up items were receiving status:needs-triage regardless of their nature, meaning items triage had already evaluated and routed could re-enter the raw-intake attention view as if they were unprocessed.

The fix is a single targeted edit to triage/SKILL.md:140. Before:

"When triage spawns follow-up work, item creation goes through the seam create-item verb… and follows the shared self-observation contract"

After:

"When triage spawns follow-up work — a fresh, orthogonal problem it surfaces but will not fix this pass, distinct from the item under evaluation and from work it has already scoped and routed — item creation goes through the seam create-item verb… and follows the shared self-observation contract… That new item is genuinely raw intake, so needs-triage is correct for it; the item triage is evaluating is never sent back to raw intake — its raw marker is cleared by the closing invariant below — and follow-up whose scope triage has already decided is routed through the outcome labels above, not filed as a self-observation."

Assessment: correct and complete. The three-way partition is explicit:

Case Treatment Grounding
Fresh, orthogonal problem (not fixable this pass) Self-observation contract → needs-triage Genuinely raw; this is the qualifying case
Item triage is currently evaluating Never needs-triage again Raw marker cleared by the closing invariant
Follow-up whose scope triage has already decided Outcome labels (step 5), not self-observation Already routed; not raw intake

The references are grounded: "closing invariant below" points to the existing invariant in the same skill; "outcome labels above" points to step 5's routing label table. Both are facts that are already in the document — the sentence surfaces them for the reader rather than asserting them in isolation.


Other wiring sites: unaffected

work/SKILL.md and scan-todos/SKILL.md don't share the same ambiguity — their filing cases are always genuinely fresh raw intake (a VALID-but-deferred finding from a post-green review, and a TODO marker requiring separate planning), so their wiring sentences need no qualification. Confirmed unchanged.


All findings across all review rounds — resolved

Finding Source Status
Triage wiring sentence scope unmissable Claude review (round 1) Fixed in 6e4c2d2
needs-triage items on autonomous frontier before triage vets them Codex P2 (round 1) Deferred to #764 — pre-existing seam gap, not introduced here ✓
Non-triage lanes inherit triage-specific during triage disclaimer wording Codex P2 (round 2) Fixed in c1df8d1
Triage-created follow-ups sent back to raw intake as needs-triage Codex P2 (round 3) Fixed in cbcbf81

Verdict: ready to merge. Four rounds of review iterated to a clean result. The extraction is precise, the wiring is scoped correctly at all three sites, all references resolve, the AI disclaimer is accurate per lane, and the triage-follow-up invariant is now explicitly stated. The two deferred items (#764 frontier semantics, #768 disclaimer SSOT) are correctly scoped to their own follow-up issues.

@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 2m 5s —— View job


Security Review — PR #762

  • Gather context and understand the request
  • Fetch PR diff (commits 1859d9ccbcbf81)
  • Read changed files
  • Analyze for security vulnerabilities
  • Post findings

No security issues found.

This PR is entirely documentation and configuration: one new markdown reference doc (dogfood-filing.md, 84 lines), three single-line wiring edits in existing SKILL.md files (with one follow-up commit expanding the triage sentence for scope clarity), a version bump in plugin.json, and a CHANGELOG entry. Every relevant attack surface was checked.

Injection (command, path, template). Each of the three SKILL.md wiring edits adds a ${CLAUDE_PLUGIN_ROOT}/reference/dogfood-filing.md reference. ${CLAUDE_PLUGIN_ROOT} is a Claude Code plugin template variable resolved by the runtime from the plugin's installation directory — it is not derived from user input, carries no shell evaluation context, and appears in instruction-text markdown rather than in run: blocks, scripts, or any executable surface. No command injection, path traversal, or template injection risk. The new dogfood-filing.md itself contains no shell commands, no run: blocks, and no evaluated expressions.

Autonomous authorization model (dogfood-filing.md lines 68–77). The doc states that autonomous lanes whose standing rules already authorize tracker mutations may create items without per-item confirmation. Two things are worth tracing here:

  1. This documents behavior that already exists in triage/SKILL.md's "Direction gate" (the same standing-rule resolution has governed autonomous triage since before this PR). It is not a new authorization grant.
  2. The phrase "already authorize tracker mutations" requires an explicit pre-existing authorization in the lane's standing rules — the track/actions/add.md authorization gate (lines 32–33) continues to be the enforcement point, with the "model-initiated filing is not [authorized]" default unchanged. dogfood-filing.md describes when that gate considers standing rules sufficient; it does not bypass the gate.

Scope of the last commit (cbcbf81). The latest commit expanded the triage wiring sentence to clarify that the self-observation contract applies only to "a fresh, orthogonal problem it surfaces but will not fix this pass, distinct from the item under evaluation and from work it has already scoped and routed." This tightening narrows the filing scope; it does not open any new execution surface.

GitHub Actions. No .github/workflows/ files were modified. No pull_request_target, workflow_run, or permissions: changes. No script injection surface via github context.

Secrets / credentials / tokens. None present or referenced in any changed file.

Supply chain / dependency pins. No new package dependencies, action pins, or external MCP connections introduced.

Information disclosure. Internal issue numbers (#477, #506, #764, #768) and plugin-relative file paths are referenced — non-sensitive project-management identifiers with no secret value.

Re: Codex P2 frontier exclusion (tracked in #764). The concern that raw needs-triage items can be selected by an autonomous /work-items:work loop before triage vets them is real and was confirmed in prior rounds. However, it is a pre-existing characteristic of the list-frontier --autonomous filter semantics in tools/work-item-tracker/CONTRACT.md, not introduced by this PR. This PR systematizes the filing behavior but does not create the frontier-filter gap. The fix belongs in the seam contract or work skill, as correctly deferred to #764.

Nothing in this changeset introduces a new executable path, external trust dependency, or policy that expands the plugin's security boundary.

@chatgpt-codex-connector chatgpt-codex-connector 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.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cbcbf81b1c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread plugins/work-items/reference/dogfood-filing.md Outdated
@kyle-sexton
kyle-sexton enabled auto-merge (squash) July 20, 2026 23:55
@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 2m 2s —— View job


PR Review: feat(work-items): extract shared self-observation filing contract (#540)

  • Gather context and understand the request
  • Read dogfood-filing.md at line 34 (new Codex P2 finding)
  • Cross-check track/actions/add.md duplicate check behavior
  • Assess new finding against existing doc logic

Latest commit (c899278) — merge from main

This is a no-content-change sync commit merging main into the branch. The PR's six changed files are unaffected. The review here focuses on the one outstanding unresolved finding: the Codex P2 from the cbcbf81 round about closed-item duplicate handling.


Codex P2 — Closed-item duplicate handling: VALID

Finding (dogfood-filing.md:34-35):

"A match means comment on the existing item instead of opening a second one."

Step 1 runs the search over --state all (open and closed). When a closed item is the only match, this rule directs the lane to comment on the closed item and stop — but closed items are absent from the triage attention view and the work frontier. The observation is buried with no path back into the queue.

Confirmed against track/actions/add.md line 36. The interactive duplicate check surfaces the state explicitly — "Similar item found: #N {title} ({state}). Add anyway, merge, or skip?" — so in the interactive path the user sees the state and can decide. The autonomous path in this contract has no equivalent safety net: it applies the "match → comment" rule without distinguishing the matched item's state.

The gap lives here, not inherited from track add. The interactive path is already safe (user sees the state). The autonomous policy is the new artifact this PR introduces, and it's the one that needs the carve-out. The fix is a prose addition to step 1 of this document only.

Recommended fix for step 1:

A match on an open item means comment on it instead of opening a second one. A match only on a closed item is treated as no-match — file a new item (and optionally link back to the closed predecessor as a References entry), since commenting on a closed issue would bury the observation outside the triage queue and needs-triage attention view.

Fix this →


All prior findings across all rounds — still resolved

Finding Source Status
Triage wiring sentence scope unmissable Claude review (round 1) Fixed in 6e4c2d2
needs-triage items on autonomous frontier before triage vets them Codex P2 (round 1) Deferred to #764
Non-triage lanes inherit triage's during triage disclaimer wording Codex P2 (round 2) Fixed in c1df8d1
Triage-created follow-ups sent back to raw intake as needs-triage Codex P2 (round 3) Fixed in cbcbf81
Closed-item duplicate comment buries observation outside triage queue Codex P2 (round 4) Open — needs decision

Verdict: one finding open. The Codex P2 on closed-item dedup handling is valid, lives in the new dogfood-filing.md (not pre-existing), and has a small targeted fix. All prior findings remain resolved. Recommend addressing before merge or explicitly deferring with a follow-up issue.

@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 2m 19s —— View job


Security Review — PR #762 (HEAD c899278)

  • Gather PR diff and changed files
  • Read new reference doc (dogfood-filing.md)
  • Read modified skill files
  • Analyze merge commit for additional attack surface
  • Post findings

No security issues found.

This PR contains one new markdown reference doc (dogfood-filing.md, 84 lines), three wiring edits in existing SKILL.md files, a version bump in plugin.json, and a CHANGELOG entry. The HEAD is a merge commit (c899278) pulling main into the branch; I reviewed both the PR's own changes and the merge surface.

Injection (command, path, template). The three SKILL.md wiring edits each add a ${CLAUDE_PLUGIN_ROOT}/reference/dogfood-filing.md reference. ${CLAUDE_PLUGIN_ROOT} is a Claude Code plugin template variable resolved by the runtime from the plugin's installation directory — not from user input, and with no shell evaluation context. These references appear exclusively in instruction-text markdown, not in run: blocks, scripts, or any executable surface. No command injection, path traversal, or template injection risk. dogfood-filing.md itself contains no shell commands, no run: blocks, and no evaluated expressions.

Autonomous authorization model (dogfood-filing.md lines 68–77). The doc states that autonomous lanes with standing rules already authorizing tracker mutations may create items without per-item confirmation. Two things are verifiable:

  1. This documents existing behavior already expressed in triage/SKILL.md's Direction gate — not a new authorization grant or a permission widening.
  2. The phrase "already authorize tracker mutations" requires an explicit pre-existing grant in the lane's standing rules. The track/actions/add.md authorization gate (line 32) remains the enforcement point, with "model-initiated filing is not [authorized]" as the default unchanged. dogfood-filing.md describes when that gate treats standing rules as sufficient; it does not bypass the gate.

Merge commit (c899278) — ci.yml and runner-policy.mjs changes. These changes came in from main via the merge commit, not from this PR's feature branch. git diff origin/main...HEAD -- .github/ returns empty, confirming no workflow files were modified on this branch. The merge-in additions (a new parse-concern-value-sync CI job using actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 with persist-credentials: false, and refactoring in runner-policy.mjs) landed on main and are outside this PR's security perimeter.

GitHub Actions. No .github/workflows/ files were modified on this branch.

Secrets / credentials / tokens. None present or referenced in any changed file.

Supply chain / dependency pins. No new package dependencies, action pins, or external MCP connections introduced.

Information disclosure. Internal issue numbers (#477, #506, #768) and plugin-relative file paths are non-sensitive project-management identifiers.

Re: Codex P2 "closed-duplicate burial" finding. The contract at line 34 ("A match means comment on the existing item instead of opening a second one") does not distinguish between open and closed matched items. Commenting on a closed issue in an autonomous lane would silently bury the observation outside the triage attention view. This is a correctness / reliability gap — a real issue — but it falls outside the security review scope (no injection, auth bypass, credential exposure, or Actions risk). It is correctly tracked in the Codex P2 thread for a dedicated fix.

Nothing in this changeset introduces a new executable path, external trust dependency, or policy that expands the plugin's security boundary.

@claude

claude Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 1m 32s —— View job


PR Review: feat(work-items): extract shared self-observation filing contract (#540)

  • Gather context and understand the request
  • Read latest diff (merge commit 518f0f5)
  • Check status of open finding: closed-item duplicate burial
  • Review current state of dogfood-filing.md
  • Post findings

Latest commit (518f0f5) — merge from main, no work-items content changed

This is a pure sync commit: git diff c899278..518f0f5 -- plugins/work-items/ returns empty. The merge brings in unrelated changes to disk-hygiene, docs-hygiene, and source-control plugins. The PR's six changed files are unchanged from the prior review round.


Open finding: closed-item duplicate burial — still unaddressed

The P2 finding first raised in the cbcbf81 Codex review and surfaced as the one outstanding issue in the prior Claude review remains present at dogfood-filing.md:34:

"A match means comment on the existing item instead of opening a second one."

Step 1 runs the dedupe search over --state all (open and closed). When the only match is a closed item, this rule silently routes the new observation to a comment on that closed issue. Closed items are absent from the needs-triage attention view and the list-frontier --autonomous query, so the observation is buried with no path back into any active queue.

Cross-check against track/actions/add.md:36: the interactive path is safe — it surfaces {state} explicitly ("Similar item found: #N {title} ({state}). Add anyway, merge, or skip?") so the user sees the state and can decide. The dogfood-filing.md autonomous contract has no equivalent safety net; it applies "match → comment" without distinguishing the matched item's state.

The fix is a prose addition in step 1 only — the interactive path (track add) is already safe:

A match on an open item means comment on it instead of opening a second one. A match only on a closed item is treated as no-match — file a new item (and optionally link back to the closed predecessor in the ## References section), since commenting on a closed issue buries the observation outside the triage attention view and needs-triage queue.

Fix this →


All findings across all review rounds

Finding Source Status
Triage wiring sentence scope unmissable Claude review (round 1) Fixed in 6e4c2d2
needs-triage items on autonomous frontier before triage vets them Codex P2 (round 1) Deferred to #764 — pre-existing seam gap ✓
Non-triage lanes inherit triage's during triage disclaimer wording Codex P2 (round 2) Fixed in c1df8d1
Triage-created follow-ups sent back to raw intake as needs-triage Codex P2 (round 3) Fixed in cbcbf81
Closed-item duplicate comment buries observation outside triage queue Codex P2 (round 4) Open — unaddressed in 518f0f5

Verdict: one finding remains open. The latest sync commit introduces no new content. The closed-item duplicate burial gap at dogfood-filing.md:34 is the new artifact this PR introduces (not pre-existing), and the fix is a one-sentence prose addition. All four prior findings remain resolved.

@claude

claude Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 1m 40s —— View job


Security Review — PR #762 (HEAD 518f0f5)

  • Gather context and understand the request
  • Fetch PR diff and read changed files
  • Analyze for security vulnerabilities
  • Post findings

No security issues found.

This PR consists of one new markdown reference doc (dogfood-filing.md, 84 lines), three wiring edits in existing SKILL.md files (one expanded across multiple prior commits), a version bump in plugin.json, and a CHANGELOG entry. I reviewed against every relevant attack surface.

Injection (command, path, template). The three SKILL.md wiring edits each add a ${CLAUDE_PLUGIN_ROOT}/reference/dogfood-filing.md reference. ${CLAUDE_PLUGIN_ROOT} is a Claude Code plugin template variable resolved by the runtime from the plugin's installation directory — not derived from user input, and with no shell evaluation context. These references appear exclusively in instruction-text markdown, not in run: blocks, scripts, or any executable surface. dogfood-filing.md itself contains no shell commands, no run: blocks, and no evaluated expressions.

Autonomous authorization model (dogfood-filing.md lines 66–77). The doc states that autonomous lanes whose standing rules already authorize tracker mutations may create items without per-item confirmation. Two facts bear verification:

  1. The authorization gate at track/actions/add.md line 32 remains the enforcement point with "model-initiated filing is not [authorized]" as the default. dogfood-filing.md describes when that gate treats standing rules as sufficient; it does not bypass the gate.
  2. This documents existing behavior already expressed in triage/SKILL.md's Direction gate — not a new authorization grant, and not a widening of the permission boundary. The scope is narrow (tracker item creation and comments only) with an AI disclaimer mandated on all autonomous output.

Closed-item duplicate burial (Codex P2, open). dogfood-filing.md line 34 says "A match means comment on the existing item instead of opening a second one" without distinguishing closed matches. The prior Claude review from this session (rounds 4–5) confirmed this is a real correctness/reliability gap — a match against a closed item buries the observation outside the triage queue. However, it falls outside the security review scope: no injection, authentication bypass, authorization widening, credential exposure, or Actions risk. It is correctly tracked as a follow-up fix rather than a blocker here.

GitHub Actions. git diff origin/main...HEAD shows no .github/workflows/ files modified on this branch. The merge commits (c899278, 518f0f5) pull in main, but the Actions changes they carry were already on main before this PR — they are not this PR's surface. No pull_request_target, workflow_run, or permissions: changes from this branch.

Secrets / credentials / tokens. None present or referenced in any changed file.

Supply chain / dependency pins. No new package dependencies, action pins, or external MCP connections introduced.

Information disclosure. Internal issue numbers (#477, #506, #768) and plugin-relative file paths are non-sensitive project-management identifiers with no secret value.

Nothing in this changeset introduces a new executable path, external trust dependency, or policy that expands the plugin's security boundary. All prior security review findings remain resolved or correctly deferred.

@claude

claude Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 1m 54s —— View job


Security Review — PR #762 (HEAD b45bb9d)

  • Gather context and understand the request
  • Read PR diff and changed files
  • Analyze for security vulnerabilities
  • Post findings

No security issues found.

This is a sync merge commit (b45bb9d) pulling in an unrelated brace-expansion version bump from main (55caeb5, touching only plugins/ai-briefing/). The PR's own work-items content is unchanged from the prior review round. I reviewed the full changeset against every relevant attack surface.

Injection (command, path, template). The three SKILL.md wiring edits each embed a ${CLAUDE_PLUGIN_ROOT}/reference/dogfood-filing.md reference. ${CLAUDE_PLUGIN_ROOT} is a Claude Code plugin template variable resolved by the runtime from the plugin's installation directory — not derived from user input, not shell-evaluated. All three references appear in instruction-text markdown, not in run: blocks, scripts, or any executable surface. dogfood-filing.md itself (84 lines, read at HEAD) contains no shell commands, no run: blocks, and no evaluated expressions — it is pure prose and relative links.

Autonomous authorization model (dogfood-filing.md lines 68–77). The doc states autonomous lanes whose standing rules already authorize tracker mutations may create items without per-item confirmation. Two facts verified at HEAD:

  1. The enforcement gate at track/actions/add.md "Authorization gate" remains the execution-time enforcement point, with "model-initiated filing is not [authorized]" as the default unchanged. dogfood-filing.md describes when that gate treats standing rules as sufficient; it does not bypass the gate.
  2. This documents behavior that already exists in triage/SKILL.md's Direction gate — not a new authorization grant and not a widening of the permission boundary. Scope is narrow (tracker item creation and comments only) with AI disclaimer required on all autonomous output.

GitHub Actions. git diff origin/main...HEAD -- .github/ returns empty — no workflow files modified on this branch. The merge commits bring in main's prior changes, but those are already reviewed on their own PRs.

Secrets / credentials / tokens. None present or referenced in any changed file.

Supply chain / dependency pins. No new package dependencies, action pins, or external MCP connections introduced. The brace-expansion bump in the merge commit touches a different plugin (ai-briefing) and its lock file only.

Information disclosure. Internal issue numbers (#477, #506, #768) and plugin-relative file paths are non-sensitive project-management identifiers.

Re: Codex P2 closed-item duplicate burial (dogfood-filing.md:34–35). Still present in HEAD — "A match means comment on the existing item instead of opening a second one" does not distinguish closed vs open matches, so a match against a closed item on an autonomous lane would bury the observation outside the triage queue. This is a real correctness/reliability gap and it remains open. However, it falls outside the security review scope: no injection, authentication bypass, authorization widening, credential exposure, or Actions risk. The interactive path is already safe (the user sees the item's state before deciding). The correctness fix is tracked in the Claude review thread from the prior round.

Nothing in this changeset introduces a new executable path, external trust dependency, or policy that expands the plugin's security boundary.

@claude

claude Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 1m 33s —— View job


PR Review: feat(work-items): extract shared self-observation filing contract (#540)

  • Gather context and understand the request
  • Read dogfood-filing.md at HEAD (b45bb9d)
  • Assess whether closed-item duplicate burial finding is addressed
  • Post review findings

Latest commit (b45bb9d) — merge from main, no dogfood-filing.md changes

This is another sync commit pulling main into the branch. The only work-items changes it carries are a 0.17.2 CHANGELOG entry (doc-only license note) and a README.md license section fix — neither touches dogfood-filing.md. The six changed files that constitute this PR's actual content are unchanged.


Open finding: closed-item duplicate burial — still unaddressed

The P2 finding first raised by Codex at cbcbf81 and flagged in the two most recent Claude reviews remains present at dogfood-filing.md:34:

"A match means comment on the existing item instead of opening a second one."

Step 1 runs the dedupe search over --state all (open and closed). When the only match is a closed item, this rule silently routes the observation to a comment on that closed issue. Closed items are absent from the needs-triage attention view and the list-frontier --autonomous query, so the observation is buried with no path back into any active queue.

The interactive path via track add is already safe — it surfaces {state} explicitly ("Similar item found: #N {title} ({state}). Add anyway, merge, or skip?"), so the user sees the state and can decide. The autonomous contract in dogfood-filing.md has no equivalent safety net.

The fix is a one-sentence addition to step 1 only:

Fix this →


All findings across all review rounds

Finding Source Status
Triage wiring sentence scope unmissable Claude review (round 1) Fixed in 6e4c2d2
needs-triage items on autonomous frontier before triage vets them Codex P2 (round 1) Deferred to #764 — pre-existing seam gap ✓
Non-triage lanes inherit triage's during triage disclaimer wording Codex P2 (round 2) Fixed in c1df8d1
Triage-created follow-ups sent back to raw intake as needs-triage Codex P2 (round 3) Fixed in cbcbf81
Closed-item duplicate comment buries observation outside triage queue Codex P2 (round 4) Open — unaddressed in b45bb9d

Verdict: one finding remains open. The latest sync commit introduces no changes to the work-items content. The closed-item duplicate burial gap at dogfood-filing.md:34 is the new artifact this PR introduces (not pre-existing in the prior skill files), and the fix is a one-sentence prose replacement. All four prior findings remain resolved.

@chatgpt-codex-connector chatgpt-codex-connector 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.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b45bb9d3d2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread plugins/work-items/reference/dogfood-filing.md
A self-observation whose only match is a closed item was told to comment on
that item. Closed items are absent from the triage attention view, so a
still-live or regressed observation would be buried where no lane re-enters it.
Distinguish open vs closed matches: an open match comments; a closed match
reopens the item (or files a fresh active one linking it) so it re-queues.
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

@claude

claude Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 2m 31s —— View job


PR Review: feat(work-items): extract shared self-observation filing contract (#540)

  • Gather context and understand the request
  • Read latest diff (commit ce16c6d)
  • Assess whether closed-item duplicate burial finding is addressed
  • Assess Codex P2 from round 5 (b45bb9d) — "Allow self-filed raw items through triage"
  • Review all outstanding findings

Latest commit (ce16c6d) — closed-duplicate burial: fixed

This commit directly addresses the last open P2 finding. At dogfood-filing.md:34–40, step 1 now reads:

"A match against an open item means comment on it instead of opening a second one. A match against a closed item is different: closed items are absent from the triage attention view, so commenting there buries a still-live or regressed observation where no lane will pick it up — reopen the closed item (or open a fresh active item that links it) so the problem re-enters the queue."

This is exactly right, and the chosen resolution is better than the "treat-as-no-match" shape suggested in the prior review: reopening the closed item preserves history and avoids a duplicate while ensuring the problem lands back in the triage queue. The fallback ("or open a fresh active item that links it") handles cases where the consumer's tracker semantics don't support reopening (e.g., a closed-as-won't-fix item that should genuinely stay closed while a fresh variant is tracked separately). Both paths ensure the observation becomes active.


Codex P2 (round 5 at b45bb9d) — "Allow self-filed raw items through triage"

The Codex P2 raised at dogfood-filing.md:59 is unaddressed in ce16c6d. Before flagging it as a merge blocker, I verified it against the triage skill.

The concern: triage/SKILL.md:38 says:

"Items published by /work-items:decompose (and team-authored /work-items:track add items) are born triaged — classified, role-labeled, and briefed at creation. They never re-enter this flow… If someone names one explicitly, say it is already triaged and stop."

The Codex read "team-authored /work-items:track add items" as encompassing autonomous-lane self-observations filed via track add.

Why this is not confirmed: The rule's own qualifier defines what "born triaged" means: "classified, role-labeled, and briefed at creation." Self-observation items are none of these — they carry status:needs-triage (a raw marker), no role label, and no brief. The rule's mechanism for excluding items from re-triage is the label check: "they carry labels from birth" (role labels like agent-ready, needs-human) — the exact labels that keep them out of the attention view. A needs-triage-labeled item carries no such exclusion label and correctly appears in the attention view (bucket 2: "status:needs-triage — explicitly tagged for evaluation").

Assessment: The Codex finding is based on a misreading of "team-authored" as meaning any agent-created item rather than team-created items that are already fully classified at birth. The actual runtime behavior is correct — a self-observation item's raw marker (needs-triage) is not a "born triaged" label, so it passes through to triage correctly. The phrasing in triage/SKILL.md:38 is slightly ambiguous about what "team-authored" covers, but that ambiguity is pre-existing in that skill and is not introduced or widened by this PR.

Classification: PLAUSIBLE (ambiguity in triage/SKILL.md) but not a blocker for this doc. A follow-up clarification to triage/SKILL.md:38 — e.g. "team-authored items that arrive already classified, role-labeled, and briefed" — would close the gap in human/model reading without changing any behavior. Out of scope for this contract-extraction PR.


All findings across all review rounds

Finding Source Status
Triage wiring sentence scope unmissable Claude review (round 1) Fixed in 6e4c2d2
needs-triage items on autonomous frontier before triage vets them Codex P2 (round 1) Deferred to #764 — pre-existing seam gap ✓
Non-triage lanes inherit triage's during triage disclaimer wording Codex P2 (round 2) Fixed in c1df8d1
Triage-created follow-ups sent back to raw intake as needs-triage Codex P2 (round 3) Fixed in cbcbf81
Closed-item duplicate comment buries observation outside triage queue Codex P2 (round 4) Fixed in ce16c6d
"team-authored track add items" phrasing ambiguous re: self-observations Codex P2 (round 5) Pre-existing ambiguity in triage/SKILL.md, not introduced here; actual runtime behavior is correct; suggest follow-up clarity edit to triage/SKILL.md:38

Verdict: ready to merge. The closed-duplicate burial fix (ce16c6d) closes the last open blocking finding. Five rounds of review iterated to a clean result: the extraction is precise, the wiring is scoped correctly at all three sites, all references resolve, the AI disclaimer is accurate per lane, the triage follow-up invariant is explicitly stated, and closed-match handling is now correct. The Codex P2 from round 5 is a pre-existing phrasing issue in a sibling skill — worth a follow-up but not a condition on this PR.

@claude

claude Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Claude finished @kyle-sexton's task in 1m 49s —— View job


Security Review — PR #762 (HEAD ce16c6d)

  • Gather context and understand the request
  • Fetch PR diff and read changed files
  • Analyze for security vulnerabilities
  • Post findings

No security issues found.

This PR is entirely documentation and configuration: one new markdown reference doc (dogfood-filing.md, 89 lines at HEAD), three wiring edits in existing SKILL.md files, a version bump in plugin.json, and a CHANGELOG entry. I reviewed the full changeset against every relevant attack surface.

Latest commit (ce16c6d) — closed-duplicate reopen. The final commit resolves the open finding from prior review rounds: "A match against a closed item is different… reopen the closed item (or open a fresh active item that links it) so the problem re-enters the queue." The reopen action is documentation of policy applied through the existing seam verbs — it does not create a new execution surface. The same track/actions/add.md authorization gate that governs all tracker mutations already governs item reopens.

Injection (command, path, template). The three SKILL.md wiring edits each add a ${CLAUDE_PLUGIN_ROOT}/reference/dogfood-filing.md reference. ${CLAUDE_PLUGIN_ROOT} is a Claude Code plugin template variable resolved by the runtime from the plugin's installation directory — not derived from user input, not shell-evaluated. All three references appear in instruction-text markdown, not in run: blocks, scripts, or any executable surface. dogfood-filing.md contains no shell commands, no run: blocks, and no evaluated expressions.

Autonomous authorization model (dogfood-filing.md lines 70–81). The doc states autonomous lanes whose standing rules already authorize tracker mutations may create items without per-item confirmation. Two facts verified at HEAD:

  1. The enforcement gate at track/actions/add.md "Authorization gate" remains the execution-time enforcement point, with "model-initiated filing is not authorized" as the default unchanged. dogfood-filing.md describes when that gate treats standing rules as sufficient; it does not bypass the gate.
  2. This documents behavior already present in triage/SKILL.md's Direction gate — not a new authorization grant and not a permission widening. Scope is narrow (tracker item creation and comments only), with AI disclaimer required on all autonomous output, naming the originating lane rather than inheriting triage-specific wording (fixed in prior commit c1df8d1).

GitHub Actions. No .github/workflows/ files were modified on this branch. No pull_request_target, workflow_run, or permissions: changes. No script injection surface via github context.

Secrets / credentials / tokens. None present or referenced in any changed file.

Supply chain / dependency pins. No new package dependencies, action pins, or external MCP connections introduced.

Information disclosure. Internal issue numbers (#477, #506, #768) and plugin-relative file paths are non-sensitive project-management identifiers with no secret value.

Re: all prior Codex P2 findings. All security-relevant findings from prior rounds are resolved or correctly deferred:

The Codex finding from the latest round ("allow self-filed raw items through triage" — triage's scope section may conflict with needs-triage items created by this contract) is a correctness/policy scoping question between two documentation sections, not a security concern: no injection, authorization bypass, or data exposure risk.

Nothing in this changeset introduces a new executable path, external trust dependency, or policy that expands the plugin's security boundary.

@kyle-sexton

Copy link
Copy Markdown
Contributor Author

Tower blitz (thread-stalled, 2h with auto-merge armed): resolving both Codex P2 threads per defer pattern.

Auto-merge already armed; merge proceeds when BLOCKED clears.

This was generated by AI (control-tower blitz, session 6).

@kyle-sexton
kyle-sexton merged commit 5910033 into main Jul 21, 2026
22 checks passed
@kyle-sexton
kyle-sexton deleted the fix/540-work-items-shared-dogfood-skill branch July 21, 2026 05:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automated Opened by automation.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

work-items: shared dogfood-filing skill — cross-lane-identical self-observation rule must not be absorbed as three private copies

1 participant