# GitHub Issues Read-Only Export Fixture V01

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

References:

- [#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 #361 by adding the smallest repo-local live read-only GitHub issue export path after the GitHub issue-body work payload template. PR #361 created the authoring shape. This slice proves that issue records using that shape can be converted into deterministic planner-readable fixture data without mutating GitHub state and without triggering execution.

The exporter answers:

- which live issue payloads can become planner input
- which issue payloads are malformed or incomplete
- which issue payloads can be normalized into the planner fixture schema
- which labels, dependencies, validation commands, closeout requirements, forbidden zones, and next-action fields are present
- which issue payloads should be rejected before planning
- whether this inspection can happen without mutating GitHub issues, PRs, labels, comments, state, or branches

## Relationship To PR #361

This work uses the issue-body work payload template from PR #361 as the input contract. The template gave humans a stable way to express objective, parent issue, dependencies, required labels, execution surface, risk class, parallelism class, allowed files or domains, forbidden zones, validation commands, acceptance criteria, closeout receipt requirements, approval gates, lock and lease expectations, retry policy, rollback expectations, non-mutation boundaries, close semantics, and post-closeout next action.

The exporter does not replace the template. It reads issue records that contain a fenced structured payload and converts valid payloads into a committed normalized fixture. Invalid or unsafe payloads remain rejected evidence.

## Relationship To PR #359

This export relates to PR #359 by producing data that can be mapped to the read-only queue planner fixture shape. The normalized fixture records work item id, source issue metadata, dependency records, required labels, risk class, execution surface, parallelism class, touched files, validation contract, closeout receipt requirements, and non-mutation confirmations.

The exporter does not invoke the queue planner. It does not promote exported items into a work queue. It only proves that issue-body payloads can be transformed into deterministic planner-readable data that a future owner-approved integration could consume.

## Relationship To PR #357

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

The exporter does not implement the work engine as a live worker. It does not claim work, renew leases, transition issue state, open branches from payloads, or run validation from exported data.

## Exporter Behavior

The script `scripts/github_issues_read_only_export_fixture.py` supports two explicit modes:

```bash
python3 -B scripts/github_issues_read_only_export_fixture.py --input validation/fixtures/github_issues_work_payload_source_v01.json --output /tmp/github_issues_export_fixture_v01.json
python3 -B scripts/github_issues_read_only_export_fixture.py --repo pinklon/ai-capability-discipline --state open --label area:workflow --output /tmp/github_issues_export_fixture_v01.json
```

The default validation is offline and deterministic. The validator runs only the `--input` path over the committed source fixture and compares the generated output to `validation/fixtures/github_issues_exported_planner_fixture_v01.json`.

The live GitHub mode is explicit and read-only. The live path requires `--repo` and uses read-only issue list and issue view inspection. It does not create, edit, close, reopen, comment on, label, assign, milestone, merge, or transition any GitHub issue or PR.

## Rejected Payloads

Rejected payloads are first-class output. The fixture records source issue metadata and rejection explanations for:

- missing fenced structured payload
- malformed structured payload
- missing required labels
- missing validation commands
- missing closeout receipt requirements
- protected closed parent misuse for #269 or #271
- forbidden mutation or execution fields

This rejection posture keeps malformed or unsafe issue bodies out of planner input. It also gives a reviewer concrete evidence for fixing an issue body before any later planning step.

## Non-Mutation Boundary

This exporter is a read-only normalization layer. It does not mutate live GitHub issues or PRs, labels, milestones, assignees, comments, issue state, PR state, branches, source registries, Preview source sets, Production source sets, Cloudflare, provider/model configuration, runtime retrieval, browser-side retrieval, or package authority.

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

#269 remains closed. #271 remains closed. #356 remains closed. #358 remains closed. #360 remains closed. `codex-automerge` was not applied.

## Future Worker Boundary

This is still not autonomous execution. A later controlled worker would require a separate owner-approved issue, explicit authority boundaries, transition rules, identity model, dry-run mode, lease handling, failure handling, review gates, mutation receipts, and validation evidence before any work could be started from exported data.

The safe next step after this v01 is an owner decision about whether the exported fixture should feed the existing read-only queue planner in a later repo-local integration. That later work must remain separate from any worker, webhook, scheduler, or live mutation path unless the owner explicitly authorizes those surfaces.