mirror of
https://github.com/dtzp555-max/memory-continuity.git
synced 2026-07-21 21:15:07 +00:00
Add minimal JIRA-like workflow to memory-continuity skill
This commit is contained in:
@@ -24,6 +24,34 @@ Use `memory/CURRENT_STATE.md` as a small overwrite-oriented workbench, not as a
|
||||
- Update only on state changes, not on a timer
|
||||
- Remove stale items instead of endlessly appending
|
||||
|
||||
## Minimal JIRA-like workflow
|
||||
|
||||
Keep the workflow small. Use these task states only:
|
||||
- `planned`
|
||||
- `dispatching`
|
||||
- `in_progress`
|
||||
- `blocked`
|
||||
- `reviewing`
|
||||
- `done`
|
||||
|
||||
State meaning:
|
||||
- `planned`: task exists and has been defined
|
||||
- `dispatching`: main has initiated delegation, but does not yet have enough evidence that the worker truly launched
|
||||
- `in_progress`: worker/session has visible execution evidence
|
||||
- `blocked`: task cannot safely proceed right now (including launch failure, stalled worker, model failure, auth/tool issues)
|
||||
- `reviewing`: deliverable exists and main is validating it
|
||||
- `done`: main has accepted the result and updated Tao
|
||||
|
||||
Evidence rule:
|
||||
- Do not upgrade a task state without an evidence point.
|
||||
- Good evidence points include: non-empty worker session history, worker accepted/milestone reply, commit, branch, PR, release, or runtime log.
|
||||
- `sessions_spawn accepted` alone is not enough to claim real progress.
|
||||
|
||||
Timeout rules:
|
||||
- If a worker has no first visible response/evidence within 10 minutes after dispatch, mark the task `blocked` with reason `launch failure`.
|
||||
- If a worker has an ETA and passes that ETA without a milestone, mark the task `blocked` with reason `stalled`.
|
||||
- Silence is not neutral; unexplained silence is a process failure signal.
|
||||
|
||||
## Dual reporting protocol
|
||||
|
||||
### Worker → main
|
||||
@@ -43,8 +71,8 @@ Preferred reply format:
|
||||
|
||||
### main → Tao
|
||||
Main must report to Tao at:
|
||||
- task accepted / formally started
|
||||
- worker dispatched
|
||||
- task formally started
|
||||
- worker truly in progress (not merely spawn-accepted)
|
||||
- blocked
|
||||
- milestone reached
|
||||
- task/phase completed
|
||||
@@ -57,7 +85,7 @@ Preferred Tao update format:
|
||||
|
||||
Ordering rule:
|
||||
- When a worker reports milestone/completion/blocker, first update `CURRENT_STATE.md`, then update Tao, then continue with review/commit/next dispatch.
|
||||
- If no evidence point exists yet (sessionKey / commit / branch / PR / log), do not claim work has already started.
|
||||
- If no evidence point exists yet (sessionKey with trace / commit / branch / PR / log), do not claim work has already started; say it is about to start.
|
||||
|
||||
## When to use the doctor
|
||||
Run `scripts/continuity_doctor.py` when:
|
||||
|
||||
@@ -24,9 +24,16 @@ The item is missing or materially broken:
|
||||
- `## Recently Finished`
|
||||
- `## Next`
|
||||
- `## Reset Summary`
|
||||
4. main `AGENTS.md` contains continuity guidance and dual reporting protocol markers
|
||||
4. main `AGENTS.md` contains continuity guidance, minimal JIRA-like workflow markers, and dual reporting protocol markers
|
||||
5. line-count caps are respected
|
||||
|
||||
## Runtime/process checks to add later
|
||||
These are not fully implemented yet, but are part of the intended workflow:
|
||||
- detect `dispatching` tasks that never produce a worker trace
|
||||
- treat no first response within 10 minutes as `blocked (launch failure)`
|
||||
- treat missed milestone ETA as `blocked (stalled)`
|
||||
- ensure main does not claim `in_progress` without evidence
|
||||
|
||||
## Suggested actions on failure
|
||||
- create missing files from template
|
||||
- restore missing AGENTS continuity section
|
||||
|
||||
Reference in New Issue
Block a user