@shivaedev/work-fleet 0.4.0 → 0.5.0
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/CHANGELOG.md +7 -0
- package/README.md +1 -1
- package/dist/host/commands.d.ts +0 -1089
- package/dist/host/commands.d.ts.map +1 -1
- package/dist/host/commands.js +1 -13
- package/dist/host/commands.js.map +1 -1
- package/dist/host/daemonClient.d.ts +1057 -1057
- package/dist/host/daemonHandlers.d.ts.map +1 -1
- package/dist/host/daemonHandlers.js +1 -1
- package/dist/host/daemonHandlers.js.map +1 -1
- package/dist/host/{status.d.ts → fleetStatus.d.ts} +1 -3
- package/dist/host/fleetStatus.d.ts.map +1 -0
- package/dist/host/{status.js → fleetStatus.js} +1 -5
- package/dist/host/fleetStatus.js.map +1 -0
- package/dist/host/releaseWork.d.ts.map +1 -1
- package/dist/host/releaseWork.js +2 -2
- package/dist/host/releaseWork.js.map +1 -1
- package/dist/packageInfo.d.ts +1 -1
- package/dist/packageInfo.js +1 -1
- package/package.json +5 -5
- package/src/host/commands.ts +1 -16
- package/src/host/daemonHandlers.ts +1 -1
- package/src/host/{status.ts → fleetStatus.ts} +0 -5
- package/src/host/releaseWork.ts +5 -2
- package/src/packageInfo.ts +1 -1
- package/dist/host/reassignWork.d.ts +0 -549
- package/dist/host/reassignWork.d.ts.map +0 -1
- package/dist/host/reassignWork.js +0 -9
- package/dist/host/reassignWork.js.map +0 -1
- package/dist/host/status.d.ts.map +0 -1
- package/dist/host/status.js.map +0 -1
- package/src/host/reassignWork.ts +0 -17
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,12 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 0.5.0 - 2026-10-18
|
|
4
|
+
|
|
5
|
+
### Breaking
|
|
6
|
+
|
|
7
|
+
- Remove `runFleet`, `continueWork` and `dispatchWork` from `host/commands.ts`, and remove `host/reassignWork.ts` and its `reassignWork` export. Run the host with `serveFleet` from `host/daemon.ts`.
|
|
8
|
+
- Remove the `renderStatus` pass-through from `host/status.ts`; import it directly from `host/renderStatus.ts`. Import `fleetStatus` from `host/fleetStatus.ts` after the module rename.
|
|
9
|
+
|
|
3
10
|
## 0.4.0 - 2026-10-18
|
|
4
11
|
|
|
5
12
|
### Added
|
package/README.md
CHANGED
|
@@ -313,7 +313,7 @@ Cloud host configuration accepts `cloud.threadNamePrefix` (default `Fleet: `), `
|
|
|
313
313
|
|
|
314
314
|
Fleet persists the session acknowledgement before naming it. Launch naming retains the acknowledged work ID and loads only that record; `src/engine/sessionNaming.spec.ts` proves one lookup with both one and 1,000 stored records, and rejection of missing or ambiguous intents without scanning other records. Naming is best-effort: a rejected or failed request logs a warning with the session ID and cause, then Fleet starts the turn. Project assignment is sent with `thread/start`. `work-fleet name-threads` reads all stored Fleet records, including archived cycles and acknowledged sessions without turns, and renames threads whose current names differ from their Fleet names. It reports each rename to stdout and each read or rename failure to stderr, then continues other sessions. Shared threads are visited once and retain their original role and context. Repeating the command skips successful names and retries failures. `src/engine/threadNames.test.ts`, `src/providers/cloudMetadataFlow.spec.ts` and `src/host/cloudThreadNamesFlow.spec.ts` cover formatting, startup ordering, best-effort failures and backfill idempotence with real PostgreSQL and a synthetic Cloud backend.
|
|
315
315
|
|
|
316
|
-
Restart the host with the same SQL namespace. An attempt intent commits before `thread/start`, its session acknowledgement commits before `turn/start`, and its turn acknowledgement commits before observation. SIGKILL tests against real PostgreSQL and a synthetic Cloud server cover both sides of these mutations and recovery of 10 concurrent attempts with lost turn acknowledgements. These tests prove host persistence and Cloud adapter wire behavior; they do not prove live hosted execution.
|
|
316
|
+
Restart the host with the same SQL namespace. An attempt intent commits before `thread/start`, its session acknowledgement commits before `turn/start`, and its turn acknowledgement commits before observation. The SIGKILL tests in `src/host/cloudRestart.spec.ts` and `src/host/cloudFanout.spec.ts` spawn `serveFleet` for the initial daemon and its restart against real PostgreSQL and a synthetic Cloud server. They cover both sides of these mutations and recovery of 10 concurrent attempts with lost turn acknowledgements. These tests prove host persistence and Cloud adapter wire behavior; they do not prove live hosted execution.
|
|
317
317
|
|
|
318
318
|
If the session ID is known, reconciliation searches all provider turn pages for the persisted operation ID and adopts the exact existing receipt. For an acknowledged Cloud thread with no turns, Fleet polls for `cloud.recoveryGraceMs` (default five seconds) to allow late acceptance to appear. If the thread remains empty, Fleet confirms its environment and starts the saved turn on that same thread, retaining the attempt and operation ID. Retry on a missing-turn decision uses the same recovery, including prepared prompts from older worker records. Recovery requires the current Board revision to remain approved. Missing or incomplete thread evidence, unrelated turns and duplicate operation matches stay blocked. If the thread acknowledgement itself was lost, the current protocol cannot locate that thread by operation ID: Fleet retains the attempt and reservation and raises a human blocker. Recovery never starts another thread for that attempt. `src/host/cloudRestart.spec.ts` proves empty-thread recovery after the configured grace, late acceptance and guided retry after SIGKILL against real PostgreSQL and a synthetic Cloud server; `src/providers/recoverTurn.test.ts` covers the grace period and uncertain evidence. Provider unavailability after session acknowledgement and a mismatched setting after thread creation also retain unresolved ownership.
|
|
319
319
|
|