You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
✨ feat(readiness-check): add --list-examples and subset refresh support
- Add --list-examples flag to list available fixture names
- Support --refresh-examples=<name[,name...]> for selective refresh
- Validate requested fixture names upfront before processing
- Add test coverage for list output and subset rewrites
✨ feat(doctor): add --prune-stale-follow-health for explicit cleanup
- Add --prune-stale-follow-health flag to remove stale snapshots
- Report prune status and reason in text/JSON output
- Preserve fresh snapshots when prune is requested
- Add test coverage for prune behavior
Copy file name to clipboardExpand all lines: docs/go/maintainer/development-tracker.md
+14Lines changed: 14 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -498,6 +498,20 @@ Current blockers:
498
498
- Blockers: none.
499
499
- Next step: decide whether the refresh helper should remain a mode on `readiness-check`, or move to a separate maintainer script if the checked-in example catalog grows further.
500
500
501
+
### 2026-03-17 Session Update
502
+
503
+
- Completed: Made the readiness example helper scale a bit better as the fixture catalog grows. `scripts/readiness-check` now supports `--list-examples` plus `--refresh-examples=<name[,name...]>`, validates requested fixture names up front, and test coverage now checks list output plus subset-only rewrites instead of assuming every refresh touches the full catalog.
504
+
- In progress: none.
505
+
- Blockers: none.
506
+
- Next step: decide whether the current list-and-subset workflow is enough for maintainers, or whether the example catalog should eventually move into a small manifest file with richer metadata.
507
+
508
+
### 2026-03-17 Session Update
509
+
510
+
- Completed: Added explicit stale follow-health pruning to `doctor`. Operators can now run `doctor --prune-stale-follow-health` to remove only stale `follow-imports.health.json` sidecars, and the doctor text/JSON report now surfaces whether a snapshot was pruned plus the prune reason. App coverage now verifies stale snapshots are removed only when requested and that fresh snapshots are preserved.
511
+
- In progress: none.
512
+
- Blockers: none.
513
+
- Next step: decide whether explicit stale pruning is enough operator hygiene, or whether a later slice should add a broader import/follow cleanup surface for old checkpoints and retry artifacts too.
Copy file name to clipboardExpand all lines: docs/go/maintainer/mcp-integration.md
+7Lines changed: 7 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -220,6 +220,13 @@ If a deliberate readiness-output change makes those fixtures drift, refresh them
220
220
go run ./scripts/readiness-check --refresh-examples
221
221
```
222
222
223
+
If you only need one or two fixtures while iterating on a specific output shape, first list the available fixture names and then refresh just the subset you want:
224
+
225
+
```powershell
226
+
go run ./scripts/readiness-check --list-examples
227
+
go run ./scripts/readiness-check --refresh-examples=ci-json
228
+
```
229
+
223
230
Then rerun `go test ./scripts/readiness-check -run TestReadinessExampleOutputsStayInSync` plus the normal repo checks so the updated fixtures are verified in read-only mode again.
Copy file name to clipboardExpand all lines: docs/go/operator/import-ingestion.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -206,6 +206,7 @@ Multi-input `follow-imports` returns one aggregate report with command-level wat
206
206
-`follow-imports` also keeps cumulative `watch_poll_catchups` and `watch_poll_catchup_bytes` counters for the lifetime of the process. Once poll catchup happens at least three times in the same process, the report adds a `WARN_FOLLOW_IMPORTS_POLL_CATCHUP` warning so operators and automation can treat notify mode as degraded even if it never fully falls back.
207
207
- Each emitted `follow-imports` report also refreshes a last-known health sidecar under the normal log directory. `codex-mem doctor` reads that snapshot so operators can inspect the most recent follow-mode watch health even after the long-lived process has already exited.
208
208
- For continuous follow mode, `doctor` now marks that sidecar as stale when it has not been refreshed for roughly three poll intervals, with a minimum freshness window of 30 seconds. Stale follow health adds `WARN_FOLLOW_IMPORTS_HEALTH_STALE` so operators can distinguish a healthy last-known state from an old snapshot left behind by a stopped process.
209
+
- If you want to clear only stale follow-health sidecars without touching fresh ones, run `codex-mem.exe doctor --prune-stale-follow-health`. The doctor report then tells you whether it actually removed a stale snapshot via `follow_imports_health_pruned` and `follow_imports_health_prune_reason`.
209
210
- When multi-input follow mode shares `--failed-output` or `--failed-manifest` base paths, `codex-mem` derives per-input file names before adding the byte-range suffix so retry artifacts from different inputs do not overwrite each other.
210
211
- Each event uses the same imported-note workflow as `memory_save_imported_note`.
211
212
- Existing explicit memory wins over weaker imported duplicates in the same project.
0 commit comments