claude-dev-env 8.102.0 → 8.102.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -110,6 +110,7 @@ Checkpoint after decisions and state changes, before waiting, and before a known
|
|
|
110
110
|
|
|
111
111
|
### Complete the requested outcome
|
|
112
112
|
|
|
113
|
+
Before a completion report or status answer, follow [completion reporting](reference/completion-reporting.md).
|
|
113
114
|
Close a task only after its evidence is checked and integrated into the task authority.
|
|
114
115
|
Close a goal only when its acceptance conditions and authorized delivery are met.
|
|
115
116
|
Keep a named pending user action open when required. Completed work needs no invented final human action.
|
|
@@ -137,6 +138,7 @@ Report the result, evidence, and any remaining limit.
|
|
|
137
138
|
| `AGENTS.md` | Skill subtree instructions. |
|
|
138
139
|
| `.claude/CLAUDE.md` | Claude instruction import. |
|
|
139
140
|
| `reference/run-state.md` | Goal records, task authority, follow list, and active-root registry. |
|
|
141
|
+
| `reference/completion-reporting.md` | Verified goal status and unfinished administrative work. |
|
|
140
142
|
| `reference/recovery.md` | Cold-start and compaction recovery. |
|
|
141
143
|
| `reference/oversee-delegated-work.md` | Spawner review of delegated work before it reaches the user. |
|
|
142
144
|
| `reference/platform-evidence.md` | Official Projects sources and coordinator report boundaries. |
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# Report completion
|
|
2
|
+
|
|
3
|
+
Use this procedure before a completion report or an answer about whether work is done.
|
|
4
|
+
|
|
5
|
+
1. Recover the user's requested outcome and acceptance conditions. Read the evidence for that outcome before choosing its status.
|
|
6
|
+
2. Check what each unfinished item changes. Missing deliverables, required verification, necessary approvals, and stated completion prerequisites keep the affected goal open. An administrative item whose absence has no effect on the result, its use, or its acceptance keeps its own task open.
|
|
7
|
+
3. State the main outcome first. When that outcome is verified complete and only incidental recordkeeping remains, report the task as complete. A requested status notice alone does not make the main outcome incomplete. Mention the administrative item separately when useful or required by the active reporting rules.
|
|
8
|
+
4. Keep unfinished work tracked honestly. When one tracker item combines the completed outcome and unfinished administration, preserve the outcome's goal and evidence, mark its work complete, and keep a separate open administrative follow-up. Do reachable administrative work before ending. Preserve its next action or blocker when it cannot be finished. Never mark it done merely to make the report look complete.
|
|
9
|
+
5. Preserve other goals and required delivery. A complete subgoal does not close an unfinished goal or the parent run. Use the goal's acceptance conditions in the [run record](run-state.md) to decide what its remaining work affects.
|
|
10
|
+
|
|
11
|
+
An administrative action can be requested without being a condition of the main outcome's completion. Treat it as a completion prerequisite when the user states that dependency, when it carries an essential requested result, or when its absence affects the result's usability, safety, or completeness.
|
|
12
|
+
|
|
13
|
+
For example, a verified report already delivered to the user is complete while an internal progress notice remains unsent. A report still missing required checks, required approval, or its requested delivery remains incomplete.
|
|
@@ -11,6 +11,12 @@
|
|
|
11
11
|
- Keep each item's status current as the work moves: in progress when you start it, completed only after you saw the proof. A long turn updates the list at each step, so the list never lags the work.
|
|
12
12
|
- An item blocked on the user stays open, and the reply says what the user must give.
|
|
13
13
|
|
|
14
|
+
## Completion reports
|
|
15
|
+
|
|
16
|
+
Judge completion against the user's outcome and acceptance conditions. Report a verified main outcome as complete when only incidental recordkeeping remains, even when that administration was requested. Missing deliverables, required verification, approvals governing the outcome, stated completion prerequisites, and work needed for usability, safety, or completeness keep the affected goal open.
|
|
17
|
+
|
|
18
|
+
When one task combines a completed outcome and unfinished administration, preserve the goal and evidence, mark the main work complete, and track administration as a separate open follow-up. Do reachable administrative work now. Report the main outcome first and mention administration separately when useful.
|
|
19
|
+
|
|
14
20
|
## Asks ledger
|
|
15
21
|
|
|
16
22
|
When the host keeps an asks ledger with `ledger.py` and `asks_check.py`, record each ask in it too:
|