# GitHub Issues Exported Planner Report V01

Issue: [#364](https://github.com/pinklon/ai-capability-discipline/issues/364)

References:

- [#362 Add live read-only GitHub issue export to committed planner fixture v01](https://github.com/pinklon/ai-capability-discipline/issues/362)
- [PR #363 Add live read-only GitHub issue export to committed planner fixture v01](https://github.com/pinklon/ai-capability-discipline/pull/363)
- [#360 Add GitHub issue-body work payload template v01](https://github.com/pinklon/ai-capability-discipline/issues/360)
- [PR #361 Add GitHub issue-body work payload template v01](https://github.com/pinklon/ai-capability-discipline/pull/361)
- [#358 Add read-only queue planner and parallelism report v01](https://github.com/pinklon/ai-capability-discipline/issues/358)
- [PR #359 Add read-only queue planner and parallelism report v01](https://github.com/pinklon/ai-capability-discipline/pull/359)
- [#356 GitHub Issues queue-backed agent work engine MVP](https://github.com/pinklon/ai-capability-discipline/issues/356)
- [PR #357 Implement GitHub Issues queue-backed agent work engine MVP v01](https://github.com/pinklon/ai-capability-discipline/pull/357)
- [#287 Queue-backed multi-agent work engine evaluation](https://github.com/pinklon/ai-capability-discipline/issues/287)
- [#277 Backlog triage dependency and supersession workflow](https://github.com/pinklon/ai-capability-discipline/issues/277)

## Purpose

This v01 follows PR #363 by adding the smallest deterministic integration report between exported issue payloads and the existing read-only planner lane model. PR #363 proved that issue-body work payload records can be exported into a committed normalized fixture without mutating GitHub state. This report consumes that committed exported fixture and shows which normalized records map to planner lanes.

The report answers:

- which exported issue payloads map to planner lanes
- which exported items are serial-required
- which exported items are safe-parallel candidates
- which exported items are blocked
- which exported items require owner decision
- which exported items are high-risk gated
- which exported payloads are rejected before planning
- which validation and closeout requirements are carried forward
- which non-mutation confirmations are preserved
- what planner input shape was derived from exported issue records
- what remains intentionally non-executing

## Relationship To PR #361

This report relates to PR #361 because the exported fixture came from issue bodies shaped by the GitHub issue-body work payload template. The report preserves template fields that matter for planning: objective-derived work item identity, parent and dependency evidence, required labels, execution surface, risk class, parallelism class, allowed files or domains, forbidden zones, validation commands, acceptance criteria, closeout receipt requirements, non-mutation boundary, and post-closeout next action.

The report does not replace the template and does not author or repair issue bodies. It consumes only the normalized committed export output.

## Relationship To PR #359

This report relates to PR #359 by reusing the existing queue planner classification logic for lane output. The adapter converts exported `normalized_items` into the planner-compatible `work_items` shape, then emits serial, safe-parallel, blocked, owner-decision, and high-risk gated lanes.

The planner lanes are produced without execution. The report invokes classification only. It does not claim work, create branches from planned data, run validation commands from payloads, change issue state, or start implementation work.

## Relationship To PR #357

This report relates to PR #357 by preserving the work engine MVP concepts of state, dependencies, risk class, parallelism class, owner-decision gates, validation contracts, closeout proof, and non-mutation boundaries.

It is still not the work engine as a worker. It does not implement autonomous execution, polling, webhook handling, scheduled execution, external queue infrastructure, Linear, Jira, custom databases, or MCP behavior.

## Why Committed Exported Fixtures

Validation uses committed exported fixtures because deterministic fixture data is the safe boundary for this integration. The validator runs against `validation/fixtures/github_issues_exported_planner_fixture_v01.json` and compares the generated report to `validation/fixtures/github_issues_exported_planner_report_v01.json`.

The validator does not call live GitHub during validation. It does not run the live export mode from PR #363. This keeps validation repeatable and prevents live issue, PR, label, comment, state, or branch mutation from entering the acceptance path.

## Rejected Exported Payloads

Rejected exported payloads remain rejected before planning. They are carried forward with source issue metadata and rejection reasons, but they are not adapted into planner input and are not classified into planner lanes.

The rejected examples cover missing fenced structured payload, malformed structured payload, missing required labels, missing validation commands, missing closeout receipt requirements, protected closed parent misuse, and forbidden mutation or execution fields.

## Source Issue Metadata

The report preserves source issue metadata for both normalized records and rejected records. The metadata includes issue number, title, state, labels, timestamps, and URL from the committed exported fixture.

This preservation lets reviewers trace planner-lane output back to the exported issue record without allowing the report to mutate that issue.

## Non-Mutation Boundary

This report is a read-only classification artifact. It does not call live GitHub, mutate live GitHub issues or PRs, change labels, assign owners, set milestones, create comments, change issue state, change PR state, create branches from report data, merge, or apply `codex-automerge`.

It does not trigger implementation work from exported or planned data. It does not add autonomous polling, scheduled execution, webhook-triggered execution, autonomous worker loops, external queue providers, Linear integration, Jira integration, a custom database, or MCP behavior.

It does not mutate source registries, Preview source sets, Production source sets, Cloudflare, Cloudflare Access/WAF, provider/model configuration, runtime retrieval semantics, browser-side provider calls, browser-side current-source retrieval, or package authority.

#269 remains closed. #271 remains closed. #277 remains closed. #287 remains closed. #356 remains closed. #358 remains closed. #360 remains closed. #362 remains closed.

## Human-Mediated Orchestration

This report supports future human-mediated orchestration by making the handoff from exported issue payloads to planner classification inspectable. A human reviewer can see which items are safe-parallel candidates, which are serial, which are blocked, which require owner decision, which are high-risk gated, and which never enter planning because they were rejected.

That visibility can support later owner decisions about sequencing, issue-body repair, or controlled worker design without letting this report become execution.

## Later Controlled Worker Boundary

A later controlled worker would require a separate owner-approved issue, explicit mutation authority, identity and audit model, dry-run mode, state transition rules, lock and lease handling, branch policy, validation execution rules, failure handling, review gates, mutation receipts, closeout semantics, and rollback evidence.

Until that separate work exists and is approved, this report remains deterministic fixture classification only and still not autonomous execution.