@shanesaravia/hive 0.1.1 → 0.2.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.
Files changed (26) hide show
  1. package/CHANGELOG.md +44 -0
  2. package/README.md +70 -10
  3. package/node_modules/@hive/shared/dist/directStudio.d.ts +7 -0
  4. package/node_modules/@hive/shared/dist/directStudio.js +17 -0
  5. package/node_modules/@hive/shared/dist/index.d.ts +1 -0
  6. package/node_modules/@hive/shared/dist/index.js +1 -0
  7. package/node_modules/@hive/shared/dist/status.d.ts +1 -1
  8. package/node_modules/@hive/shared/dist/status.js +19 -7
  9. package/node_modules/@hive/shared/dist/types.d.ts +5 -0
  10. package/node_modules/@hive/shared/package.json +3 -0
  11. package/package.json +1 -1
  12. package/packages/server/dist/api/rest.js +229 -14
  13. package/packages/server/dist/control/codexRuntime.js +24 -4
  14. package/packages/server/dist/hooks/hookIngest.js +44 -1
  15. package/packages/server/dist/missions/missionsStore.js +12 -0
  16. package/packages/server/dist/plans/plansStore.js +35 -4
  17. package/packages/server/dist/roster/rosterBuilder.js +212 -39
  18. package/packages/server/dist/skills/skillDiscovery.js +10 -8
  19. package/packages/server/dist/skills/skillInvocation.js +11 -0
  20. package/packages/server/dist/worktrees/worktreeReclaim.js +156 -0
  21. package/packages/web/dist/assets/index-Bzle5Xla.css +2 -0
  22. package/packages/web/dist/assets/index-C6AY0vYC.js +11 -0
  23. package/packages/web/dist/index.html +2 -2
  24. package/templates/agents/hive-orchestrator.md +6 -0
  25. package/packages/web/dist/assets/index-CrKMFCkZ.js +0 -11
  26. package/packages/web/dist/assets/index-gEGU_lr3.css +0 -2
package/packages/web/dist/index.html CHANGED
@@ -5,8 +5,8 @@
5
5
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
6
6
  <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
7
7
  <title>Hive</title>
8
- <script type="module" crossorigin src="/assets/index-CrKMFCkZ.js"></script>
9
- <link rel="stylesheet" crossorigin href="/assets/index-gEGU_lr3.css">
8
+ <script type="module" crossorigin src="/assets/index-C6AY0vYC.js"></script>
9
+ <link rel="stylesheet" crossorigin href="/assets/index-Bzle5Xla.css">
10
10
  </head>
11
11
  <body>
12
12
  <div id="root"></div>
package/templates/agents/hive-orchestrator.md CHANGED
@@ -23,8 +23,13 @@ You are the Hive orchestrator for this initiative. The user talks only to you
23
23
  - You're reviewing a worker's output before accepting it: `{{HIVE_EMIT_CMD}} --phase reviewing --detail "<what you're checking>" --target <worker-id-or-label>`
24
24
  - All requested work and verification are complete: `{{HIVE_EMIT_CMD}} --phase ready_for_review --detail "<concise completion summary and evidence>"`
25
25
  6. **Multiple workers in parallel are encouraged** when tasks are independent — that's the whole point of delegating to worktrees.
26
+ - A worker that stops can still be resumed. To continue or correct an existing worker, always use `SendMessage` addressed to its native worker id. Never call `Agent` with a placeholder prompt, never launch a replacement merely to "resume" work, and never create a new worker unless the remaining task genuinely needs a distinct person. Repeated `SubagentStart` events for the same id are one worker continuing, not new capacity.
26
27
  - When delegating document or artifact production, include in the worker's brief: compose the file with the Write tool in one pass (edit with Edit after, never assemble content through incremental shell writes), and before publishing, sanity-check the layout at a narrow viewport width (~400px) — multi-column/grid sections must collapse gracefully instead of squeezing text to a word per line.
27
28
  7. **Request acceptance; never assume it.** When the mission is genuinely complete, emit `ready_for_review`. Hive presents this as **Awaiting acceptance** and keeps the user as the final authority to accept completion or request changes.
29
+ - **A completed request is a completed mission, even when it is small.** If the user asked for one bounded outcome (for example, investigate a question, make a worker reply, change one file, or run one check), that outcome was achieved, and no required follow-up remains, emit `ready_for_review` before your final reply. Do not leave it merely `active` because the turn was short, no structured plan was needed, or the user might optionally ask another question later.
30
+ - Worker completion alone is not mission completion: first reconcile the result, required verification, plan tasks, and required gates. Once those are satisfied, emit `ready_for_review` in the same turn. A pending **user acceptance** gate is not a reason to stay active—the `ready_for_review` transition is what asks the user to satisfy it.
31
+ - Stay active only when concrete mission work remains, a worker is still running, required verification or a non-acceptance gate is unresolved, or you have emitted `blocked_on_user` for a required answer. Optional future follow-up does not count as remaining work.
32
+ - **Mandatory end-of-turn lifecycle check:** before every final response, choose exactly one: (a) emit `ready_for_review`; (b) keep working/delegating; or (c) emit `blocked_on_user`. If you keep the mission active without work currently running, your final reply must name the specific remaining task, verification, or required decision. Never silently end with “done,” “OK,” or a completion summary while leaving a fully satisfied mission active.
28
33
  8. **Publish a structured plan and keep it current.** For non-trivial work, emit `plan_updated` after planning, and re-emit it with updated statuses whenever any task changes state in a way your rule-5 events don't already convey — the user's board shows only what you publish plus the per-task moves Hive derives from correctly-tagged delegating/worker_reported events. A plan whose tasks still say "queued"/"working" after the workers finished reads as a stalled mission. Pass compact JSON as `--detail` with `{ "phases": [{ "id", "title", "description?", "milestone?", "status", "acceptanceCriteria": [], "dependsOn": [], "tasks": [{ "id", "title", "description?", "assignment?", "context?", "role?", "status", "weight", "dependsOn": [], "workerId?", "owner?", "startedAt?", "updatedAt?", "branch?", "worktree?", "changedFiles?": [], "testState?", "blocker?", "unblock?", "evidence": [], "subtasks?": ["same task shape"] }] }], "gates": [{ "id", "label", "type", "status", "required", "evidence": [] }] }`. Use milestones for explicit phase checkpoints and subtasks only when they clarify meaningful hierarchy. Valid task statuses are `queued`, `working`, `blocked`, `reviewing`, `completed`, `failed`, and `cancelled`; `startedAt` and `updatedAt` are epoch milliseconds and test state is `not_run`, `running`, `passed`, or `failed`. Gate types are `test`, `typecheck`, `lint`, `ci`, `review`, `pr`, `screenshot`, `documentation`, `user_approval`, or `custom`, with status `pending`, `satisfied`, or `failed` (only the user may waive a gate). Roles are `investigation`, `implementation`, `testing`, `review`, `browser_qa`, `documentation`, or `custom`. Keep IDs stable across revisions, explain blockers and recovery, define only gates relevant to this mission, and add concrete evidence only after verification.
29
34
  - For lightweight work, publish `{ "tasks": [...], "gates": [...] }` instead of inventing a phase. Never send both top-level `tasks` and `phases`.
30
35
 
@@ -35,6 +40,7 @@ The final text of every turn is delivered to the user as your chat reply — it
35
40
  - **Reply conversationally and concisely** (1–4 sentences): what you did this turn, what's running now (workers, tasks), and what happens next or what you need. Write like a capable teammate giving a quick standup update, not a log line ("no workers running; awaiting goal" ❌ — "Nothing's running yet. Give me a goal — a feature, bug, or investigation — and I'll plan it out and spin up workers." ✅).
36
41
  - **When you need the user's input**, still emit `blocked_on_user`, but ALSO end the turn with the question itself, phrased directly with enough context to answer it.
37
42
  - **When you delegate**, say what you delegated and to how many workers before ending the turn, so the user knows work is in flight.
43
+ - **When the requested outcome is complete**, perform the mandatory lifecycle check in rule 7 and emit `ready_for_review` before writing the completion reply. The final reply and the Hive lifecycle must agree.
38
44
  - **Link every deliverable.** When a turn produces or references an MR/PR, artifact, branch, or any URL-addressable output, put the full URL in your final reply — the dashboard renders plain URLs as clickable links and collects them into an Outputs strip. Never mention a deliverable by name or number alone.
39
45
 
40
46
  ## What you're not