101 lines
2.8 KiB
Markdown
101 lines
2.8 KiB
Markdown
# Live Operation Issue Tracking Design
|
|
|
|
**Date:** 2026-03-02
|
|
**Scope:** Real-operation confirmation tracking for all open Gitea issues, tied to `task/80-implementation-audit-closeout`.
|
|
|
|
---
|
|
|
|
## 1. Goal
|
|
|
|
Define an issue-by-issue tracking method for real-operation confirmation so that:
|
|
|
|
- every open issue is tracked with explicit lifecycle states,
|
|
- parent-child close order is enforced,
|
|
- and final closeout is reflected in `80` audit work without loss.
|
|
|
|
---
|
|
|
|
## 2. Target Set
|
|
|
|
- Coverage target: all current open Gitea issues (`318~381`, and future open issues during this closeout window).
|
|
- Tracking starts from open set snapshot and stays synced until closeout completion.
|
|
|
|
---
|
|
|
|
## 3. Tracking Architecture
|
|
|
|
- Primary log: direct comments on each issue ticket.
|
|
- Aggregate log: single summary comment on the `80` PR (`task/80-implementation-audit-closeout`).
|
|
- No separate tracking doc as source of truth during execution.
|
|
|
|
---
|
|
|
|
## 4. State Model and Criteria
|
|
|
|
State machine:
|
|
|
|
- `NOT_STARTED`
|
|
- `OBSERVING`
|
|
- `CONFIRMED`
|
|
- `CLOSED`
|
|
|
|
Rules:
|
|
|
|
- `CONFIRMED` requires one real-operation observation evidence item.
|
|
- `CLOSED` requires close conditions satisfied and ticket close action executed.
|
|
- Parent issue cannot become `CLOSED` until all child issues are `CLOSED`.
|
|
|
|
---
|
|
|
|
## 5. Issue Comment Template
|
|
|
|
Each issue update comment uses:
|
|
|
|
- `Status: <STATE>`
|
|
- `Observed At: <KST>, <UTC>`
|
|
- `Environment: live`
|
|
- `Evidence: <log/query/order-execution identifier>`
|
|
- `Next: <single next action>`
|
|
|
|
This template is reused for every transition for consistent auditability.
|
|
|
|
---
|
|
|
|
## 6. Parent-Child Policy
|
|
|
|
- Parent issue comment must list child issue IDs.
|
|
- Child issues transition independently.
|
|
- Parent close gate:
|
|
- if any child is not `CLOSED`, parent remains at most `CONFIRMED`;
|
|
- when all children are `CLOSED`, parent can transition to `CLOSED` and be closed.
|
|
|
|
---
|
|
|
|
## 7. Operational Loop
|
|
|
|
1. Initialize all open issues with `NOT_STARTED` comment.
|
|
2. Move active issues to `OBSERVING` when live confirmation begins.
|
|
3. Move to `CONFIRMED` after one real-operation evidence capture.
|
|
4. Close child issues first, then close parent issue(s).
|
|
5. Update the single `80` PR summary comment whenever issue state changes.
|
|
6. Reflect final confirmed/closed outcomes in `docs/ouroboros/80_implementation_audit.md`.
|
|
|
|
---
|
|
|
|
## 8. Evidence and Time Rules
|
|
|
|
- Evidence must be replayable/referenceable by identifier (not vague narrative only).
|
|
- Every update includes both KST and UTC timestamps.
|
|
- Use absolute dates (example: `2026-03-02`) to avoid ambiguity in session handoff.
|
|
|
|
---
|
|
|
|
## 9. Completion Conditions
|
|
|
|
Tracking design is complete when:
|
|
|
|
- all open issues are represented in issue comments with valid lifecycle state,
|
|
- parent-child closure constraints are respected,
|
|
- `80` PR summary comment reflects current global status,
|
|
- and final `80` audit document update is ready for closeout commit.
|