Project priority audit silently omits items beyond 1,000

[Chris0Jeky]

Problem

scripts/github/Sync-TaskdeckProjectPriority.ps1 defaults to -Limit 1000 and reports a clean audit when that cap is saturated, without proving that all project items were inspected. On 2026-07-24 it reported scanned: 1000, needsUpdate: 0, while targeted project-item reads showed both issue #1456 and PR #1457 had Priority I labels but an empty project Priority field.

This violates the project-automation invariant that no issue or PR item may have empty Priority, and can make handoffs claim clean metadata when newer project items were never audited.

Evidence

• project: Taskdeck Execution Claude/create feature f 01 qr r as j4 s14advm nn qhp2 la #1 (PVT_kwHOA47lx84BPH_r)
• issue item Restore Taskdeck Codex deny-floor adapter and prove live hook trust #1456: PVTI_lAHOA47lx84BPH_rzgz6qPs, Status Review, Priority null
• PR item Add pinned Codex deny-floor adapter #1457: PVTI_lAHOA47lx84BPH_rzgz64fg, Status Pending, Priority null
• expected option for both: Priority I (392f0497)
• canonical audit result immediately beforehand: scanned: 1000, needsUpdate: 0
• the script calls gh project item-list ... --limit $Limit and audits only the returned items; it does not detect saturation or paginate/fail closed

Acceptance criteria

• Audit/apply mode examines every issue and PR item in the configured project, using reliable pagination or another complete retrieval path.
• If completeness cannot be established, the script exits nonzero and does not print a clean result.
• Add regression coverage for a project with more than 1,000 items or an equivalent mocked pagination/saturation case.
• Repair project Priority for Restore Taskdeck Codex deny-floor adapter and prove live hook trust #1456 and Add pinned Codex deny-floor adapter #1457 to Priority I and verify them with targeted reads.
• Re-run the full project audit and prove no issue/PR project item has empty or mismatched Priority.
• Update docs/GITHUB_PROJECT_AUTOMATION.md and docs/TESTING_GUIDE.md if the invocation or verification contract changes.

Scope

Project-automation substrate only. Do not change product behavior. Treat the current empty #1456/#1457 priorities as a merge-gate metadata defect, separate from #1457's human /hooks trust gate.

[Chris0Jeky]

Initial remediation evidence

Targeted project-item writes repaired the immediate metadata defect and targeted GraphQL reads verified the result:

• Restore Taskdeck Codex deny-floor adapter and prove live hook trust #1456 item PVTI_lAHOA47lx84BPH_rzgz6qPs: Status Review, Priority Priority I (392f0497)
• Add pinned Codex deny-floor adapter #1457 item PVTI_lAHOA47lx84BPH_rzgz64fg: Status Pending, Priority Priority I (392f0497)
• Project priority audit silently omits items beyond 1,000 #1458 item PVTI_lAHOA47lx84BPH_rzgz89ag: Status Pending, Priority Priority I (392f0497)

The script defect remains open: its capped bulk read can still omit items and falsely report a clean audit. No repository implementation or regression test has been attempted because Taskdeck tracked mutation remains blocked by #1457's failed runtime-hook activation gate.

[Chris0Jeky]

Duplicate evidence migrated from #1474

The later duplicate reproduced the same defect with a larger live project:

• default -Limit 1000: 1,000 scanned, 0 updates, false all-clear;
• -Limit 3000: 1,444 scanned, 288 updates.

That evidence strengthens this issue's complete-pagination and fail-closed acceptance criteria; it does not create a separate implementation scope. #1458 remains canonical. The current live project has since grown beyond that snapshot.

[Chris0Jeky]

Immediate-wrap handoff (2026-07-26): draft PR #1488 is pushed at 74af364c3bf7f3b4cc8b957a6a263a7dad4730ca.

Local final gates: parser 0; SelfTest 53/53 in normal and compatibility modes; docs/Golden/GitHub-ops gates pass; failure-ledger renderer tests 3/3; diff check passes; commits are DCO-signed. The former capped 1,000-item false all-clear is now recorded as an open durable failure.

Live read-only facts: a complete 1,458-item snapshot found 130 project Issues without Priority labels (83 Done, 5 Review, 42 Pending). A later 1,459-item typed pass ignores PR #123 correctly. A targeted ProjectV2 read proved GitHub exposes external Issue dotnet/efcore#35983 as a closing reference on 12 historical Taskdeck Dependabot PRs; all project content items themselves are Taskdeck-owned. The final helper rejects all cross-repository Issue authority by default.

No -Apply or remediation write ran. Because the maintainer requested immediate wrap, fresh exact-head adversarial review, Codex review, and CI on 74af364c are not complete; earlier-head evidence is superseded. Resume at PR #1488: run those gates, then classify the 130 project Issues and decide only whether any explicit future cross-repository opt-in is wanted before any reviewed apply/final zero-drift audit.