Cover Project Intake item-add responses and read-after-add races

[codeforester]

Goal

Make Project Intake consume the live GitHub Projects V2 item-add response correctly and tolerate bounded read-after-add latency, with hermetic regression tests that prove a successfully added issue is reconciled without creating a duplicate item.

Background

The supported Base gate is green on current main (7ac42b2): 1,115 Python tests passed, and branch-aware coverage passed at 90.41% statements, 80.47% branches, and 87.97% combined.

Hosted Project Intake runs still exposed an uncovered timing path. Runs 33637199268, 33638784869, and 33638820780 failed in Reconcile Project item after gh project item-add returned an item ID, with:

Project item '<id>' was not returned after it was added.

Creation of this issue exposed a second fixture-contract gap in run 33641915511. The GraphQL path fell back to REST, the REST POST /projectsV2/10/items created the issue card, and the workflow then failed with:

REST Project item add did not return an item id.

The workflow parses .value.id, and tests/github_workflow_test_support.py fakes the same nested response. The live endpoint returned a different top-level shape; an independent REST readback found exactly one created item. tests/test_project_intake_workflow.py therefore covers adding a missing Project item only against a non-live response fixture, and its primary-path fake also makes the new item immediately visible instead of simulating stale item-list responses.

Scope

• Extend the Project Intake test harness with a delayed-visibility scenario where item creation succeeds but the first post-add lookup omits the new item.
• Make the REST item-add fixture match the live endpoint response and add a regression test for extracting the created item ID from that shape.
• Add a focused regression test for the primary Project path that proves reconciliation succeeds once the added item becomes visible.
• Use a bounded retry/backoff or an equivalent exact-item read strategy after a successful add.
• Preserve duplicate prevention, exact repository/issue matching, existing-field preservation, and fail-closed behavior after the bounded retry is exhausted.
• Keep .github/workflows/project-intake.yml and templates/project-intake.yml identical.

Acceptance Criteria

• A hermetic test fails against the current immediate-read behavior and simulates at least one stale post-add lookup.
• A live-shaped REST item-add response yields the created item ID and proceeds to field reconciliation.
• Project Intake succeeds after bounded delayed visibility without adding a second Project item.
• A permanently missing added item still fails with an actionable diagnostic after the bounded retry is exhausted.
• Existing GraphQL, REST fallback, authentication, rate-limit, idempotence, and field-preservation tests remain green.
• The repository statement, branch, and combined coverage ratchets remain enabled and pass.

Validation

BASE_CLI_SOURCE_DIR=../base-cli/lib/python \
PYTHONPATH=../base-cli/lib/python:lib/python:cli/python \
python -m pytest tests/test_project_intake_workflow.py -q

BASE_BASH_LIBS_DIR=../base-bash-libs/lib/bash \
BASE_CLI_SOURCE_DIR=../base-cli/lib/python \
TZ=UTC env -u BASE_HOME ./bin/base-test

Non-Goals

• Adding an unbounded retry or hiding persistent Project API failures.
• Weakening authentication, repository/issue identity, or Project-field verification.
• Changing Project defaults or the standard issue template.

Project Fields

• Status: Ready
• Priority: P1
• Area: CI
• Initiative: Contract Hardening
• Size: M
• Milestone: v1.9.0

Agent Assignment

• Assignee: codeforester
• Agent-ready: Yes. The hosted failure, fake GitHub seam, and expected bounded behavior are explicit.