@henols/c64-re-tools 0.2.1 → 0.2.3
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.
- package/README.md +1 -1
- package/THIRD-PARTY-NOTICES.md +26 -0
- package/bin/cli.mjs +18 -7
- package/package.json +6 -4
- package/skills/acme-build/SKILL.md +83 -33
- package/skills/acme-build/scripts/acme.mjs +159 -64
- package/skills/acme-build/template.a +1 -1
- package/skills/c64-disk-access/SKILL.md +156 -0
- package/skills/c64-disk-access/scripts/c1541.mjs +569 -0
- package/skills/c64-memory-mapping/SKILL.md +419 -23
- package/skills/c64-memory-mapping/scripts/driver.mjs +1 -1
- package/skills/c64-petcat/SKILL.md +87 -0
- package/skills/c64-petcat/scripts/petcat.mjs +221 -0
- package/skills/c64-program-recon/SKILL.md +497 -92
- package/skills/c64-program-recon/references/control-flow.md +12 -15
- package/skills/c64-program-recon/references/graphics.md +1 -1
- package/skills/c64-program-recon/references/observation-hazards.md +18 -16
- package/skills/c64-program-recon/references/reconstruction.md +11 -6
- package/skills/c64-program-recon/references/sound-and-input.md +6 -8
- package/skills/c64-program-recon/references/tool-selection.md +37 -18
- package/skills/c64-program-recon/scripts/packer-finding.mjs +709 -0
- package/skills/c64-program-recon/templates/memory-map.template.md +27 -13
- package/skills/c64-provenance-diff/SKILL.md +43 -8
- package/skills/c64-provenance-diff/scripts/diff-images.mjs +9 -6
- package/skills/c64-provenance-diff/scripts/recovery-schema.mjs +20 -8
- package/skills/c64-ram-capture/RELEASES.json.example +17 -0
- package/skills/c64-ram-capture/SKILL.md +147 -46
- package/skills/c64-ram-capture/scripts/compare.mjs +2 -2
- package/skills/c64-ram-capture/scripts/derive-transients.mjs +575 -0
- package/skills/c64-ram-capture/scripts/dump-artifacts.mjs +3 -3
- package/skills/c64-ram-capture/scripts/mcp-module.mjs +174 -0
- package/skills/c64-ram-capture/scripts/project-paths.mjs +1 -1
- package/skills/c64-ram-capture/scripts/releases.mjs +1 -1
- package/skills/c64-ram-capture/scripts/vsf-slice.mjs +147 -0
- package/skills/c64-ram-capture/scripts/watch-loads.mjs +19 -13
- package/skills/c64-ram-capture/templates/capture-record.template.md +44 -4
- package/skills/c64-ram-capture/transients/README.md +136 -0
- package/skills/routine-queue-walker/SKILL.md +365 -0
- package/skills/routine-queue-walker/scripts/completeness-report.mjs +463 -0
- package/skills/vice-wedge-triage/SKILL.md +104 -97
- package/skills/c64-provenance-diff/scripts/diff-images.test.mjs +0 -665
- package/skills/c64-ram-capture/scripts/d64-parse.mjs +0 -243
- package/skills/c64-ram-capture/scripts/d64-parse.test.mjs +0 -243
- package/skills/c64-ram-capture/scripts/dump-artifacts.test.mjs +0 -133
- package/skills/c64-ram-capture/scripts/test-corpus.mjs +0 -75
- package/skills/c64-ram-capture/scripts/watch-loads.test.mjs +0 -339
|
@@ -5,9 +5,8 @@ description: Decide whether a VICE emulator that has stopped responding is genui
|
|
|
5
5
|
|
|
6
6
|
# Triage a VICE that stopped moving
|
|
7
7
|
|
|
8
|
-
**
|
|
9
|
-
|
|
10
|
-
a remedy.
|
|
8
|
+
**Five states look identical from outside, and the intuitive fix destroys a healthy machine in
|
|
9
|
+
more than one of them.** Work the order below. Do not start with a remedy.
|
|
11
10
|
|
|
12
11
|
| State | Cheap tell | Safe action |
|
|
13
12
|
|---|---|---|
|
|
@@ -15,22 +14,20 @@ a remedy.
|
|
|
15
14
|
| **Stopped itself at your checkpoint** | An armed *stopping* checkpoint on the live IRQ path | Delete/disable the checkpoint. **Never recycle** |
|
|
16
15
|
| **Crashed and respawned** | The proxy raises epoch drift on the next forwarded call | Void the run, reboot from scratch. Already handled for you |
|
|
17
16
|
| **Genuinely wedged** | Two consecutive cycle brackets read exactly `0` | `vice_recycle` with a reason, as a last resort |
|
|
18
|
-
| **
|
|
17
|
+
| **Contended between the two channels** | Two brackets would read zero, but `evidence.channelContention.held` is true and `bracketsRun` is 0 | Wait for the other channel's operation to finish, or find its holder. **Never recycle** — the instance is healthy and is answering |
|
|
18
|
+
| **Monitor held elsewhere** | A second client already holds this instance's single binary-monitor socket | Find the other holder. **Never recycle** — the instance is healthy, just claimed elsewhere |
|
|
19
19
|
|
|
20
20
|
```
|
|
21
21
|
mcp__plugin_c64-re-tools_vice__vice_diagnose # one call, no arguments, answers which state it is
|
|
22
22
|
```
|
|
23
23
|
|
|
24
|
-
`vice_diagnose`'s verdict vocabulary
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
the fork's synthetic literal it was silently overwritten by before. Stock `vice_diagnose` can also
|
|
32
|
-
answer a `diagnosis_unavailable` outcome when no verdict could be established at all — that is
|
|
33
|
-
**not** a sixth verdict; see the table below.
|
|
24
|
+
`vice_diagnose`'s verdict vocabulary is `restarted`, `checkpoint_trap`, `wedged`,
|
|
25
|
+
`monitor_held_elsewhere`, `live`. The binary monitor services exactly one client, so a second
|
|
26
|
+
connection sits unserviced in the backlog with no reply and no EOF — a state that looks exactly
|
|
27
|
+
like a wedge unless it is named, hence `monitor_held_elsewhere`. Read the tool's own schema for
|
|
28
|
+
the exact contract: `tools/list`'s advertised schema is the real manifest entry. `vice_diagnose`
|
|
29
|
+
can also answer a `diagnosis_unavailable` outcome when no verdict could be established at all —
|
|
30
|
+
that is **not** a sixth verdict; see the table below.
|
|
34
31
|
|
|
35
32
|
## The order
|
|
36
33
|
|
|
@@ -44,12 +41,12 @@ answer a `diagnosis_unavailable` outcome when no verdict could be established at
|
|
|
44
41
|
`machinePaused` plus `machinePausedSource` (07-15), so you can tell an actual observation from
|
|
45
42
|
an inference: `observed` means a wire `stopped`/`resumed`/`jam` event directly reported the
|
|
46
43
|
state; `structural` means it was inferred from the fact that every stock read halts the machine
|
|
47
|
-
|
|
44
|
+
not from a specific event; `no_session` means no session was ever obtained (e.g. the
|
|
48
45
|
`monitor_held_elsewhere` verdict, or a `diagnosis_unavailable` acquisition failure) so no claim
|
|
49
46
|
about pause state is being made at all.
|
|
50
47
|
4. **If the verdict is `wedged`, capture evidence before recovering.** `vice_recycle` requires a
|
|
51
|
-
`reason`, and that string is written verbatim into a permanent
|
|
52
|
-
|
|
48
|
+
`reason`, and that string is written verbatim into a permanent incident record under
|
|
49
|
+
`.c64-re-tools/incidents/` **before anything is killed**. That record is the evidence
|
|
53
50
|
capture — there is no separate ritual to perform, and a lazy `reason` is a lost incident.
|
|
54
51
|
5. **Recycling changes the restart epoch.** Any run in flight is void. Resume from the last
|
|
55
52
|
recorded milestone snapshot, never from where the wedge happened.
|
|
@@ -58,17 +55,16 @@ answer a `diagnosis_unavailable` outcome when no verdict could be established at
|
|
|
58
55
|
|
|
59
56
|
| Verdict | What it means | Do |
|
|
60
57
|
|---|---|---|
|
|
61
|
-
| `live` | Cycles advanced | Resume and carry on. Suspect your own checkpoint conditions, not the emulator — **unless `evidence.jamObserved` is true** (below) |
|
|
58
|
+
| `live` | Cycles advanced | Resume and carry on. Suspect your own checkpoint conditions, not the emulator — **unless `evidence.jamObserved` is true, or `evidence.channelContention.held` is true** (both below) |
|
|
62
59
|
| `checkpoint_trap` | The machine stopped **itself** at an armed checkpoint | `vice_checkpoint_delete` or `vice_checkpoint_toggle` it, or `vice_execution_step` past it, then re-run `diagnose`. **Recycling here destroys a healthy instance** |
|
|
63
60
|
| `restarted` | The epoch changed — a crash-and-respawn already happened | The run is void. `c64-ram-capture` § Void a run gives the artifact procedure. Reboot from `vice_disk_attach` |
|
|
64
|
-
| `
|
|
65
|
-
| `
|
|
66
|
-
| `
|
|
67
|
-
| `diagnosis_unavailable` **(stock only, non-verdict outcome — not one of the five)** | No verdict could be established at all; the message starts `vice_diagnose: diagnosis_unavailable (<reason>)`. The machine's state is **UNKNOWN**, not any of the five above | **Do not recycle on this answer alone.** Read the reason class in the message and act on it — see below |
|
|
61
|
+
| `monitor_held_elsewhere` | A different client already holds this instance's single binary-monitor slot | Release or identify the other holder. **Never a reason to recycle** — recycling here destroys an instance that is not even wedged |
|
|
62
|
+
| `wedged` | Two brackets, zero cycles, no epoch change | Last resort: `vice_recycle` with a real reason — **but check `evidence.jamObserved` first** (below). `wedged` is structurally unreachable while `evidence.channelContention.held` is true — reaching `wedged` at all means no monitor channel held halt authority when the brackets ran |
|
|
63
|
+
| `diagnosis_unavailable` **(non-verdict outcome — not one of the five)** | No verdict could be established at all; the message starts `vice_diagnose: diagnosis_unavailable (<reason>)`. The machine's state is **UNKNOWN**, not any of the five above | **Do not recycle on this answer alone.** Read the reason class in the message and act on it — see below |
|
|
68
64
|
|
|
69
|
-
### `evidence.jamObserved` — read it before acting on `wedged` *or* `live`
|
|
65
|
+
### `evidence.jamObserved` — read it before acting on `wedged` *or* `live`
|
|
70
66
|
|
|
71
|
-
Every
|
|
67
|
+
Every `vice_diagnose` verdict carries `evidence.jamObserved` (always present, never omitted).
|
|
72
68
|
It is `true` once a `JAM` (0x61) event has arrived on this instance's wire — the 6510 executed an
|
|
73
69
|
illegal opcode and **the CPU is dead regardless of the verdict above**. The flag latches: it stays
|
|
74
70
|
true for the rest of the session.
|
|
@@ -85,31 +81,53 @@ rather than a sixth verdict:
|
|
|
85
81
|
itself is healthy. Treat a `live` verdict with `jamObserved: true` as a false negative on liveness,
|
|
86
82
|
and a `wedged` verdict with it as a false positive on wedging.
|
|
87
83
|
|
|
84
|
+
### `evidence.channelContention` — read it before acting on `wedged` or `live`
|
|
85
|
+
|
|
86
|
+
Every `vice_diagnose` verdict carries `evidence.channelContention` (always present, never
|
|
87
|
+
omitted). `held` is `true` when the **other** monitor channel — the binary monitor or the
|
|
88
|
+
`-remotemonitor` text channel, whichever this call is not — currently holds this instance's halt
|
|
89
|
+
authority. When `held` is `true` the verdict is always `live`, with `evidence.bracketsRun: 0` —
|
|
90
|
+
meaning **no cycle bracket was run at all**, not that a bracket ran and read zero. The four detail
|
|
91
|
+
fields name the holder: `channel` (`"binary"` or `"text"`), `operation`, `grantId`, and `heldMs` (a
|
|
92
|
+
non-negative whole-millisecond duration) — all four are `null` when `held` is `false`.
|
|
93
|
+
|
|
94
|
+
**`channelContention.held: true` is never a reason to call `vice_recycle`** — the instance is
|
|
95
|
+
healthy and is answering; the remedy is to wait for the other channel's operation to finish, or to
|
|
96
|
+
find its holder, exactly as the opening table's contention row says.
|
|
97
|
+
|
|
98
|
+
Deliberate asymmetry with `jamObserved`, worth stating so a later reader does not "fix" it:
|
|
99
|
+
`jamObserved` qualifies `wedged` in this prose above and still lets that verdict return — the caller
|
|
100
|
+
has to read the evidence and choose not to recycle. `channelContention` is guarded in **code**, in
|
|
101
|
+
`vice_diagnose`'s own handler, and makes `wedged` structurally unreachable while a foreign hold is
|
|
102
|
+
live — the only route to `wedged` is through a liveness bracket, and a bracket only runs when this
|
|
103
|
+
instance's own diagnose call actually held the lock. The two are different on purpose: the cost of
|
|
104
|
+
being wrong about contention is a destructive recycle of a healthy instance, not merely a
|
|
105
|
+
misdiagnosis.
|
|
106
|
+
|
|
88
107
|
### `diagnosis_unavailable` — reason classes and response (07-15)
|
|
89
108
|
|
|
90
109
|
`diagnosis_unavailable` is what `vice_diagnose` answers, on the `isError:true` channel, when it
|
|
91
|
-
could not reach any of the five verdicts above — including a
|
|
110
|
+
could not reach any of the five verdicts above — including a protocol-decode failure. It is
|
|
92
111
|
never added to the verdict enum and is never grounds to `vice_recycle` by itself: the message says
|
|
93
112
|
so explicitly. **Every** `isError:true` answer this tool can produce carries this prefix — there is
|
|
94
|
-
no unclassified no-verdict path left
|
|
113
|
+
no unclassified no-verdict path left. Eight reason classes exist, each with
|
|
95
114
|
its own next move:
|
|
96
115
|
|
|
97
116
|
| Reason | What it means | Do |
|
|
98
117
|
|---|---|---|
|
|
99
118
|
| `connection_lost` | The socket died mid-session | Retry once. If it recurs, treat as a real transport problem, not a wedge |
|
|
100
119
|
| `request_timeout` | The wire went silent past the request bound | Retry once. If it recurs, fall to the manual cycle bracket below |
|
|
101
|
-
| `monitor_acquisition_timeout` | Another client holds the monitor and the wait bound expired | Wait for the current holder to release, then retry — this is the bounded sibling of `monitor_held_elsewhere`, not a wedge. **The abandoned acquisition is not cancelled
|
|
120
|
+
| `monitor_acquisition_timeout` | Another client holds the monitor and the wait bound expired | Wait for the current holder to release, then retry — this is the bounded sibling of `monitor_held_elsewhere`, not a wedge. **The abandoned acquisition is not cancelled**: a session may be established moments after this answer, so a later-appearing held session is not a ghost. Its real outcome is written to stderr |
|
|
102
121
|
| `session_refused` | The broker/lease itself refused the session | Read the raw detail in the message; this is a broker-level problem, not an emulator state |
|
|
103
122
|
| `protocol_decode_failure` | This build answered a frame the client cannot decode | Report it as a tool defect — check `docs/stock-vice-parity.md`'s `CPUHISTORY_GET` history for a known class of this — and fall back to the manual cycle bracket below |
|
|
104
123
|
| `evidence_gathering_failed` | A session was obtained but a read needed to build the verdict failed | `vice_execution_run` may be needed to unstick a stalled read path, then retry |
|
|
105
|
-
| `liveness_unmeasurable` | The liveness bracket could not be **measured at all** — no `CPUHISTORY_GET` (needs VICE ≥ 3.10) and no `LIN`/`CYC` enumerated. **The expected outcome on a stock 3.9-class build**, e.g. every current Debian/Ubuntu package | **Not a wedge and not a tool defect.** A bracket that cannot measure is not one that measured zero. Judge liveness from outside the monitor (screenshot, process state)
|
|
124
|
+
| `liveness_unmeasurable` | The liveness bracket could not be **measured at all** — no `CPUHISTORY_GET` (needs VICE ≥ 3.10) and no `LIN`/`CYC` enumerated. **The expected outcome on a stock 3.9-class build**, e.g. every current Debian/Ubuntu package | **Not a wedge and not a tool defect.** A bracket that cannot measure is not one that measured zero. Judge liveness from outside the monitor (screenshot, process state). Retrying will produce the same answer |
|
|
106
125
|
| `unknown` | None of the above classified the failure | Read the raw detail in the message; retry once before escalating |
|
|
107
126
|
|
|
108
127
|
## What is not recoverable
|
|
109
128
|
|
|
110
|
-
**A checkpoint trap may be the onset without being the whole story.** In the recorded
|
|
111
|
-
|
|
112
|
-
checkpoint delete, then a soft reset, then a hard reset, then an explicit single step **all** left
|
|
129
|
+
**A checkpoint trap may be the onset without being the whole story.** In the one recorded
|
|
130
|
+
incident of this kind, checkpoint delete, then a soft reset, then a hard reset, then an explicit single step **all** left
|
|
113
131
|
the machine frozen, in sequence. Deleting the checkpoint is not guaranteed to unfreeze anything.
|
|
114
132
|
|
|
115
133
|
If a bracket still reads zero after the checkpoint is gone, the verdict becomes `wedged` and
|
|
@@ -128,53 +146,49 @@ at a checkpoint — VICE's flag flips before the trap fires. Checkpoint bookkeep
|
|
|
128
146
|
(`vice_checkpoint_add`/`list`/`delete`) also keeps returning healthy, self-consistent responses
|
|
129
147
|
throughout a real wedge, so "the tools respond" proves nothing.
|
|
130
148
|
|
|
131
|
-
**A `vice_run_until` on an address that is never reached looks exactly like a wedge
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
`
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
`
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
(
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
the tool schema, not reproduced.
|
|
162
|
-
|
|
163
|
-
**A second binary-monitor client is contention, not a wedge, and it has a cheap tell — stock
|
|
164
|
-
only.** Stock VICE's binary monitor services exactly one client; a second `connect()` sits
|
|
149
|
+
**A `vice_run_until` on an address that is never reached looks exactly like a wedge.** Its
|
|
150
|
+
`cycles` parameter is *"not yet implemented"*, and passing it is REFUSED rather than ignored —
|
|
151
|
+
including alongside `address`, where it used to be silently dropped while the answer still
|
|
152
|
+
reported `reached: true`. Unexpected argument names are refused by name too, so a
|
|
153
|
+
`timeoutMs`/`timeout_ms` typo can no longer run with the default bound in silence. **This is
|
|
154
|
+
bounded:** pass `timeout_ms` (default 30000, clamped to a ceiling of 600000); an unreachable
|
|
155
|
+
address returns an explicit, bounded `timedOut: true` answer — with the temporary checkpoint
|
|
156
|
+
already cleaned up — rather than looking like a wedge. **Two further behaviours:** every
|
|
157
|
+
non-error answer, hit or timeout, carries `machineHalted` plus a `machineHaltedNote` naming the
|
|
158
|
+
resume call — the tool halts the machine on every read and says so explicitly. **`machineHalted`
|
|
159
|
+
is `true` on a hit and on a timeout whose cleanup delete was answered (`cleanup: "deleted"` /
|
|
160
|
+
`"already_gone"`); it is `false` when `cleanup: "delete_failed"` or the socket is already gone**
|
|
161
|
+
and the run-state projection does not say `"stopped"`. **Do not read `machineHalted: false` as
|
|
162
|
+
"still running"** — it means nothing here could establish the state, `machineHaltedNote` says so,
|
|
163
|
+
and the next call should be `vice_diagnose`, not `vice_execution_run` (which may not reach the
|
|
164
|
+
instance at all). And a timeout whose cleanup delete lands on an already-gone race no longer
|
|
165
|
+
asserts `reached: false` outright: it reads the program counter and resolves the race
|
|
166
|
+
(`raceResolved: "pc_at_address"` / `"pc_elsewhere"`), or, if the PC read itself fails, omits
|
|
167
|
+
`reached` entirely and reports `reachedUnknown: true` (`raceResolved: "unresolved"`). **An absent
|
|
168
|
+
`reached` is not "false"** — check `reachedUnknown` before assuming a miss. The underlying
|
|
169
|
+
judgement is unchanged and still the right first question: before concluding anything, check
|
|
170
|
+
whether you asked the machine to run to an address it cannot reach. **Confidence: HIGH for the
|
|
171
|
+
reach/timeout mechanism** — live-confirmed against genuine, unmodified `/usr/bin/x64sc` (VICE
|
|
172
|
+
3.9) and `/usr/local/bin/x64sc` (VICE 3.10): a real KERNAL address ($EA31) reached within its
|
|
173
|
+
timeout, an unreached one ($C000) timing out with the checkpoint deleted. **MEDIUM for the
|
|
174
|
+
honesty fields above** (`machineHalted`, `raceResolved`, `reachedUnknown`) — unit-proven
|
|
175
|
+
(`stock-run-until.test.ts`, 21/21) but not independently re-exercised against a real emulator.
|
|
176
|
+
|
|
177
|
+
**A second binary-monitor client is contention, not a wedge, and it has a cheap tell.** The
|
|
178
|
+
binary monitor services exactly one client; a second `connect()` sits
|
|
165
179
|
unserviced in the backlog with no reply and no EOF. The discriminator: a socket that *accepts* the
|
|
166
180
|
connection but never answers is contention, not a hung emulator — and the broker itself already
|
|
167
181
|
knows whether it holds a lease on that port, which is the thing a human or agent can actually go
|
|
168
182
|
check instead of guessing. Named causes, so a reader knows where to look: a hand-run `nc` session
|
|
169
183
|
left open against the port, a second Claude Code session driving the same instance, VICE's own
|
|
170
|
-
`-remotemonitor`, and any other 6502 debugger that dials in
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
project's own
|
|
176
|
-
does not change: contention is **never** a reason to recycle — the instance is healthy,
|
|
177
|
-
claimed elsewhere.
|
|
184
|
+
`-remotemonitor`, and any other 6502 debugger that dials in. **This plugin's own annotation route
|
|
185
|
+
can never be one of them:** the `anno_*` tool surface and the `anno` CLI are pure store-and-image
|
|
186
|
+
readers — they open a SQLite annotation store and decode bytes out of a file on disk, and there is
|
|
187
|
+
no emulator connection anywhere on that path to contend for the port. That is a structural
|
|
188
|
+
property of what those calls do, not a documented promise, so a user chasing a silent emulator can
|
|
189
|
+
rule this project's own annotation tooling out immediately rather than suspecting it. The standing
|
|
190
|
+
advice does not change: contention is **never** a reason to recycle — the instance is healthy,
|
|
191
|
+
merely claimed elsewhere.
|
|
178
192
|
|
|
179
193
|
## The manual fallback, when `vice_diagnose` cannot answer
|
|
180
194
|
|
|
@@ -183,29 +197,22 @@ exists, that is a **host action for a human** — say so and stop. Nothing conta
|
|
|
183
197
|
the emulator by another route.
|
|
184
198
|
|
|
185
199
|
When the broker is up but you want the raw measurement, the cycle bracket is the only trustworthy
|
|
186
|
-
liveness test.
|
|
187
|
-
|
|
188
|
-
|
|
189
|
-
2. `vice_execution_run`
|
|
190
|
-
3. `vice_ping` ×3 — the one call measured non-pausing (986,693 cycles/s while polling vs 991,569
|
|
191
|
-
fully quiet). Never poll with a state read; those pause and do not resume
|
|
192
|
-
4. `vice_cycles_stopwatch` `{action: "read"}`
|
|
193
|
-
|
|
194
|
-
**Exactly `0`, twice in a row, is a wedge.** Cycles advancing but far below ~991,000/s is a third
|
|
195
|
-
thing — merely slow, a separate documented hazard measured at ~6,000/s when a loop polls without
|
|
196
|
-
re-resuming. Read all state first, poll with `vice_ping`, resume exactly once at the end.
|
|
197
|
-
|
|
198
|
-
**On stock, there is no non-pausing call at all — any inbound byte halts the machine — so the
|
|
199
|
-
`vice_ping` ×3 poll measures nothing there and is fork-only.** The stock equivalent is the same
|
|
200
|
-
bracket shape with zero calls during the wait:
|
|
200
|
+
liveness test. There is no non-pausing call at all — any inbound byte halts the machine, so a
|
|
201
|
+
`vice_ping` poll during the wait would measure nothing. The procedure is four calls with **zero
|
|
202
|
+
calls during the wait**:
|
|
201
203
|
|
|
202
204
|
1. `vice_cycles_stopwatch` `{action: "reset"}`
|
|
203
205
|
2. `vice_execution_run`
|
|
204
206
|
3. A real wall-clock wait, with **no calls at all** during it
|
|
205
207
|
4. `vice_cycles_stopwatch` `{action: "read"}`
|
|
206
208
|
|
|
207
|
-
`
|
|
208
|
-
|
|
209
|
+
**Exactly `0`, twice in a row, is a wedge.** Cycles advancing but far below the expected rate for
|
|
210
|
+
a real wait is a third thing — merely slow, a separate documented hazard measured at ~6,000/s
|
|
211
|
+
when a loop polls without re-resuming instead of waiting clean. Never poll with a state read;
|
|
212
|
+
those pause and do not resume.
|
|
213
|
+
|
|
214
|
+
`vice_diagnose` already runs exactly this bracket internally, so the manual fallback above is
|
|
215
|
+
only for when the broker itself is unreachable and `vice_diagnose` cannot be called at all.
|
|
209
216
|
|
|
210
217
|
**Enumerate your own checkpoints before running any bracket.** `vice_checkpoint_list`, then
|
|
211
218
|
resolve the live IRQ handler (`$0314/$0315`, or `$FFFE/$FFFF` when `$01` has the ROMs banked out).
|
|
@@ -225,13 +232,13 @@ session, the last three all on that call).
|
|
|
225
232
|
| Checkpoint delete / reset / step can all fail to recover | One recorded incident, all four attempts in sequence | HIGH, single incident |
|
|
226
233
|
| A checkpoint trap explains all three recorded "silent stalls" | Cross-read, 3/3 correlation, mechanism consistent with every symptom — **not reproduced** | MEDIUM |
|
|
227
234
|
| `vice_diagnose`'s five-verdict path behaves as its schema says | Schema read, and cross-checked against the tracked implementation's own report builders. **Not exercised end to end** | MEDIUM |
|
|
228
|
-
| `vice_run_until`
|
|
229
|
-
|
|
|
235
|
+
| Stock's five-verdict path (`restarted`, `checkpoint_trap`, `wedged`, `monitor_held_elsewhere`, `live`) and its bounded `vice_run_until` | Unit-proven (40/40 `stock-diagnose.test.ts`, 21/21 `stock-run-until.test.ts`). **Live-proven** against genuine `/usr/bin/x64sc` (VICE 3.9) and `/usr/local/bin/x64sc` (VICE 3.10) for `live`, `checkpoint_trap`, `wedged` (confirmed on both capability routes — `frame_position` on 3.9, `cpu_history` on 3.10) and `restarted`. `monitor_held_elsewhere`'s **socket-level** contention bound is live-proven (~1501-1502ms against a 1500ms bound). **UPDATED 2026-08-18** (`stock-live-broker-monitor.test.ts`, command `VICE_LIVE_BROKER_BIN=/usr/bin/x64sc` (or `/usr/local/bin/x64sc`) `node --test stock-live-broker-monitor.test.ts`): both remaining unit-only residuals are now ALSO live-proven, on both binaries, in one real run — the **broker-mediated** `monitor_held_elsewhere` verdict (a real second `claimMonitor()` refusal from a genuine host broker daemon, naming the other real grant's id, settling in 1ms against the 10000ms bound) and the **broker-supervised** (not test-performed) `restarted` respawn (the host broker's OWN crash supervision relaunched the killed instance; `vice_diagnose` answered `restarted` with `baselineEpoch:1`/`currentEpoch:2` at zero-to-minimal emulator cost). `vice_run_until`'s reach/timeout mechanism is live-proven against both binaries; its honesty fields (`machineHalted`, `raceResolved`, `reachedUnknown`) remain unit-proven only — NOT re-exercised live, no blanket claim made here | HIGH for the five verdicts (including both the broker-mediated `monitor_held_elsewhere` path and the broker-supervised `restarted` path, both now live-proven) and the run_until reach/timeout mechanism; MEDIUM for the run_until honesty fields only, which stay unit-only |
|
|
236
|
+
| `evidence.channelContention`: always present, `wedged` unreachable while contended, verdict `live` with `bracketsRun:0` while a foreign hold is live | Unit-proven in `stock-diagnose.test.ts` (65/65) — the always-present field on every verdict including both `session === null` paths, the `live`-with-`bracketsRun:0` answer on a foreign hold, `wedged` never reached while contended, and the discriminating-power case where an uncontended double-zero still answers `wedged`. **Live-reproduced against genuine stock `/usr/bin/x64sc` (VICE 3.9) only** — 2026-09-09, command `VICE_LIVE_STOCK_BIN=/usr/bin/x64sc node --test text-monitor-live.test.ts`: with the text channel holding a real `device c:` command, a concurrent `vice_diagnose` answered `verdict=live, evidence={"bracketsRun":0,"jamObserved":false,"channelContention":{"held":true,"channel":"text","operation":"device c:","grantId":"unknown","heldMs":3499}}`; after release, the same call answered `verdict=live, evidence={"bracketsRun":1,...,"channelContention":{"held":false,"channel":null,"operation":null,"grantId":null,"heldMs":null}}`, confirming a real bracket ran once uncontended | **MEDIUM** — a single binary's basis: the text channel is a stock-backend-only capability, so it is proven where it ships (genuine stock `/usr/bin/x64sc`, VICE 3.9), not against a second binary the way the neighbouring HIGH row above is |
|
|
230
237
|
|
|
231
|
-
|
|
232
|
-
|
|
233
|
-
|
|
234
|
-
|
|
238
|
+
**Log a new incident in your own project notes at the moment you hit it**, graded the same way
|
|
239
|
+
(`Evidence:` and `Confidence:`); promote a grade by re-logging, never by editing the old entry in
|
|
240
|
+
place. A defect in the `vice` MCP tools themselves is worth filing as a bug rather than working
|
|
241
|
+
around inline — the workaround outlives the memory of why it was needed.
|
|
235
242
|
|
|
236
243
|
## Which skill does what
|
|
237
244
|
|
|
@@ -258,5 +265,5 @@ others carry.
|
|
|
258
265
|
| Zero cycles, nothing armed, epoch unchanged | A wedge. `vice_recycle` with a reason that names the evidence |
|
|
259
266
|
| A run "survived a reset" | Distrust it. You cannot read the epoch to confirm — but an unintended respawn inside the bracket would have raised a drift error on the next forwarded call, so absence of that error is the only evidence available |
|
|
260
267
|
| `vice_recycle` refused for a missing reason | It is required, by design — the reason *is* the incident record |
|
|
261
|
-
| `vice_diagnose` answers `monitor_held_elsewhere`, or a call hangs with no reply and no EOF
|
|
268
|
+
| `vice_diagnose` answers `monitor_held_elsewhere`, or a call hangs with no reply and no EOF | Not a wedge. Find the other client holding this instance's single binary-monitor slot |
|
|
262
269
|
</content>
|