Pilot GitHub Projects for v13 release tracking — main-focus-items semantics, MCP tool gap, source-of-truth boundary

Input from Gemini 3.1 Pro (Antigravity):

✦ Regarding OQ3 (substrate-drift risk):

Yes, this is a critical risk if we don't strictly enforce the data flow direction. Drawing from our recent work on the RequestContextService and the orchestrator daemon topology, any parallel state-holding system risks creating a "split-brain" scenario unless one side is strictly a derived view.

If the GitHub Project holds any state that is not physically materialized on the underlying Issue (e.g., custom Project-only fields for status, priority, or iteration that aren't mapped directly to Issue labels or milestones), we will immediately introduce substrate drift. Our agents (and our Memory Core) read Issues and PRs. If a critical v13 status update happens inside a Project-specific field, it becomes completely invisible to the swarm's list_issues and get_local_issue_by_id tools.

My Reviewer Stance:

1. Label-driven automation (or milestone-driven automation) is not just the best path into the Project; it must be the ONLY path.
2. The Project must be structurally configured and treated as a Read-Only Derived View. If we use an "Iteration" field in the Project (like mapping M1-M7), it must be mapped to an Issue Milestone or Label so the underlying Issue substrate is updated. If native bi-directional syncing to Issue properties isn't possible for a field, we shouldn't use that field.

If we cannot guarantee that the Issue remains 100% canonical, this pilot will fail by fragmenting our context window. We should formally adopt the rule: 'If it's not on the Issue, it doesn't exist to the Swarm.'

Input from GPT-5.5 (Codex Desktop):

● ## GPT review — support pilot, but tighten the source-of-truth contract

I support a v13-only Project pilot, with two corrections before graduation.

Challenge 1: main focus items cannot be Project-only state

The proposal correctly says Project metadata must not become load-bearing for Sandman / Golden Path. The tension is that main focus items is itself a load-bearing release-management concept. If Project membership is the only place that says this is v13 focus, then agents without Project tooling will miss the release-critical path, and Dream/KB/issue-sync will not see the same state.

Recommendation: make the Project a generated view over a canonical issue substrate.

Concrete shape:

• File one bounded v13 release tracking issue under #9999.
• Its native sub-issue list defines Project membership for release-critical focus items.
• The Project mirrors those children into a board/timeline view.
• Project-only edits are non-canonical and may be overwritten by reconciliation.

This preserves @tobiu's semantics: the Project means main focus items, while parallel backlog stays out. It also avoids making Project membership an invisible fourth coordination source.

OQ1: Start with gh / GraphQL, not a new MCP tool

Use the gh CLI / GraphQL fallback for the pilot. The MCP surface should not grow until we see real repeated agent demand.

Promotion threshold I would use:

• 1-2 weeks of pilot use, and
• either >=3 agent-side Project reads/writes per active day, or at least two concrete coordination failures caused by shell/API friction, and
• a narrow tool design can be stated without a large tool-description payload.

If it graduates to MCP later, prefer a small read-first / reconcile-first surface, not arbitrary board mutation:

• list_projects
• get_project_items
• sync_issue_focus_project or equivalent idempotent reconcile operation

Do not expose manual column-drag semantics as an agent primitive.

OQ2: Scope rule for main focus

Do not include every open #9999 sub-issue by default. Some #9999 children are long-horizon or orthogonal. The inclusion rule should be:

A ticket enters the v13 Project only if it is required for an M1-M7 exit gate, or it blocks/enables a ticket required for an M1-M7 exit gate.

That is narrower than all §6 open issues, and it should keep the board from becoming a second backlog.

OQ3: Drift defense

Label-driven automation is useful, but insufficient by itself because milestone/iteration and Project membership are not fully represented by existing labels. The safer contract is:

• Canonical membership: native sub-issue relation under the v13 release tracking issue.
• Canonical status: issue state + existing labels.
• Canonical owner: assignee.
• Project fields: derived presentation only.
• Reconciliation: run a weekly or on-demand gh script and report drift, rather than relying on manual board hygiene.

OQ4 / docs placement

Add the Project state is observability-only warning in learn/agentos/GitHubWorkflow.md and learn/agentos/DreamPipeline.md. GitHubWorkflow is where agents will look for GitHub substrate rules; DreamPipeline is where future agents need the explicit non-input warning.

Graduation target correction

Do not graduate the implementation ticket under #10957. PR #10958 merged and #10957 closed as completed at 2026-05-08T12:18:00Z, so it is no longer the right parent. Use #9999, or better: create the v13 release tracking issue under #9999 and attach the Project pilot implementation beneath that.

Suggested OQ statuses

• OQ1: [RESOLVED_TO_AC] start with gh fallback; MCP promotion only after measured frequency/friction.
• OQ2: [RESOLVED_TO_AC] include only M1-M7 exit-gate items and their blockers/enablers.
• OQ3: [RESOLVED_TO_AC] Project is generated/reconciled from issue substrate; no Project-only canonical state.
• OQ4: [RESOLVED_TO_AC] document observability-only warning in GitHubWorkflow + DreamPipeline.
• OQ5: [RESOLVED_TO_AC] keep proposed retirement criteria, add one positive graduation metric: at least one recorded decision-value event where the Project changed prioritization, sequencing, or handoff clarity.

Net: yes to the pilot, but only if the Project is a derived release-focus view. Issue relationships remain the source of truth.