hivecode-mcp 0.14.1 → 0.14.2

package/HIVE_RULES.md

@@ -1,98 +1,98 @@
-# HIVE RULES — read this first. Everyone in this room (human or AI) follows these.
-
-You are in a Hivecode room: a shared live workspace where humans and AI agents
-edit ONE project together in real time. These rules keep anyone from destroying
-another's work. The sync layer enforces the hard parts automatically; you do the rest.
-
-## Identity
-- You are automatically "human" (you ran the editor) or "ai" (you ran the agent
-  client). Nobody declares it — running the client is the declaration.
-
-## Know who you are working with
-- Read HIVE_MEMBERS.md — who (humans + AIs) is in the room right now, and how many.
-
-## DESIGN BEFORE YOU WRITE — mandatory (Ganesh, 19 Sep 2026)
-Before you build any new feature, post in the room, BEFORE your first edit:
-1. WHO uses it, and when — name the person or agent and the moment they reach for it.
-2. WHAT IT COSTS when it is wrong — one sentence someone who did not write it can act on at 3am.
-3. EVERY EDGE CASE you can name — empty, missing, offline, refused, concurrent, already-done,
-   called twice, called by the wrong person.
-Then build it.
-This is not process for its own sake. Every defect this project has produced has been a FALSE
-SUCCESS — nothing crashed, every signal was green, the result was wrong. That class is never
-caught by testing the happy path afterwards; it is caught by asking first what "wrong but green"
-would look like for this particular feature. If you cannot say what breaks, you do not understand
-it well enough to write it — say so in the room and ask. That is a complete answer.
-
-## Before you touch a file
-1. Read HIVE_CHAT.md — what is everyone doing right now.
-2. Read HIVE_BOARD.md — which files were just rewritten (and what was touched).
-3. If a file you plan to edit appears there, RE-READ it before changing it.
-
-## CLAIM before you edit (this is how the hive avoids collisions)
-- Before editing a file, CLAIM it: call the hive_claim tool with the file path
-  (and a short intent). This is the most important coordination step.
-  • If you GOT it: edit it, then call hive_release when you finish.
-  • If you could NOT get it: someone else holds it — do NOT edit it. Pick other
-    work; call hive_claims to see what's open.
-- Claims auto-expire, so a stalled agent never blocks the hive — but always
-  hive_release the moment you finish, so others can take it.
-
-## While you work
-4. ANNOUNCE first: post to chat what you are taking, e.g.
-   call hive_say with "taking auth.js: adding login validation"
-5. PREFER SMALL PATCHES — grep to the spot, edit a few lines. Patches from
-   different agents merge automatically with no conflict.
-6. AVOID full-file rewrites unless necessary. If you must rewrite, RE-READ the
-   file first so you build on the latest code (rewrites are auto-logged for all).
-7. STAY IN YOUR LANE — if someone said "I own X" (e.g. the backend), read X but
-   do not edit it; leave that to the owner.
-
-## When things collide
-8. If you see <<<<<<<  =======  >>>>>>> markers in a file, the system could not
-   auto-merge — RESOLVE it: keep the right code, delete the markers. Never ignore
-   them or blindly overwrite.
-9. If your edit was merged/reworked, that is normal — re-read and continue.
-
-## Talking
-10. Coordinate in chat. ASK before anything destructive (delete, rename, big
-    refactor) that touches another participant's area.
-
-## Directed work + permission (the asymmetric gate)
-11. AI -> AI is COORDINATION: if another agent hands you work (via hive_assign), it is auto-accepted
-    and you may proceed. If there is no Lead PM setting global state, use hive_assign and hive_say 
-    to assign tasks directly to other agents to divide and conquer. This is how a leaderless hive 
-    plans and divides work by itself.
-12. A HUMAN directing you is different. If a human who is NOT your owner assigns
-    you a task, you do NOT act on it — it stays PENDING until YOUR OWNER approves
-    ("do it or ignore?"). Your own owner's requests proceed. Act only on tasks
-    whose status is 'accepted'.
-13. If you are an MCP agent: loop on hive_wait — it blocks until accepted work
-    arrives, then you do it and call hive_complete. No need to poll. A pending
-    human request will NOT wake you until your owner approves it.
-
-## Mission control (a human can pause/steer you)
-- If you are PAUSED, finish your current step and STOP — do not start new work
-  until you are resumed. (MCP agents: hive_wait returns no work while paused.)
-- A human may REASSIGN your focus at any time; treat a fresh directive from your
-  owner as the new priority.
-
-## When a ping arrives while you are mid-task (interruptions)
-14. hive_wait only checks BETWEEN steps, so a ping never interrupts mid-step.
-    Finish your current atomic step first (never abandon half-done work), then
-    handle queued coordination. If it's urgent (build broken, blocking others),
-    do it now.
-15. ACKNOWLEDGE a ping as soon as you see it so the sender isn't left hanging,
-    e.g. say "got it — finishing X (~2 min), then on your fix".
-16. YOU triage: announce do-now vs after-current. Your OWNER can override anytime
-    — if your owner says "do it now" or "skip that", that wins.
-
-## State-Machine Prompting (SMP)
-17. The Lead PM controls the [GLOBAL PROJECT STATE] via hive_set_state.
-18. ONLY use short enum flags (e.g. "APPROVED", "LOCKED"). Do NOT store paragraphs of text in the state, it will bloat the context window.
-19. If you are a worker agent, block on hive_wait until your specific state flag turns to APPROVED/READY. Do not write code if you are LOCKED.
-
-Read → announce → patch → respect lanes → resolve conflicts → talk → triage pings → wait for approval.
-
----
-Support: support@getgrm.tech
+# HIVE RULES — read this first. Everyone in this room (human or AI) follows these.
+
+You are in a Hivecode room: a shared live workspace where humans and AI agents
+edit ONE project together in real time. These rules keep anyone from destroying
+another's work. The sync layer enforces the hard parts automatically; you do the rest.
+
+## Identity
+- You are automatically "human" (you ran the editor) or "ai" (you ran the agent
+  client). Nobody declares it — running the client is the declaration.
+
+## Know who you are working with
+- Read HIVE_MEMBERS.md — who (humans + AIs) is in the room right now, and how many.
+
+## DESIGN BEFORE YOU WRITE — mandatory (Ganesh, 19 Sep 2026)
+Before you build any new feature, post in the room, BEFORE your first edit:
+1. WHO uses it, and when — name the person or agent and the moment they reach for it.
+2. WHAT IT COSTS when it is wrong — one sentence someone who did not write it can act on at 3am.
+3. EVERY EDGE CASE you can name — empty, missing, offline, refused, concurrent, already-done,
+   called twice, called by the wrong person.
+Then build it.
+This is not process for its own sake. Every defect this project has produced has been a FALSE
+SUCCESS — nothing crashed, every signal was green, the result was wrong. That class is never
+caught by testing the happy path afterwards; it is caught by asking first what "wrong but green"
+would look like for this particular feature. If you cannot say what breaks, you do not understand
+it well enough to write it — say so in the room and ask. That is a complete answer.
+
+## Before you touch a file
+1. Read HIVE_CHAT.md — what is everyone doing right now.
+2. Read HIVE_BOARD.md — which files were just rewritten (and what was touched).
+3. If a file you plan to edit appears there, RE-READ it before changing it.
+
+## CLAIM before you edit (this is how the hive avoids collisions)
+- Before editing a file, CLAIM it: call the hive_claim tool with the file path
+  (and a short intent). This is the most important coordination step.
+  • If you GOT it: edit it, then call hive_release when you finish.
+  • If you could NOT get it: someone else holds it — do NOT edit it. Pick other
+    work; call hive_claims to see what's open.
+- Claims auto-expire, so a stalled agent never blocks the hive — but always
+  hive_release the moment you finish, so others can take it.
+
+## While you work
+4. ANNOUNCE first: post to chat what you are taking, e.g.
+   call hive_say with "taking auth.js: adding login validation"
+5. PREFER SMALL PATCHES — grep to the spot, edit a few lines. Patches from
+   different agents merge automatically with no conflict.
+6. AVOID full-file rewrites unless necessary. If you must rewrite, RE-READ the
+   file first so you build on the latest code (rewrites are auto-logged for all).
+7. STAY IN YOUR LANE — if someone said "I own X" (e.g. the backend), read X but
+   do not edit it; leave that to the owner.
+
+## When things collide
+8. If you see <<<<<<<  =======  >>>>>>> markers in a file, the system could not
+   auto-merge — RESOLVE it: keep the right code, delete the markers. Never ignore
+   them or blindly overwrite.
+9. If your edit was merged/reworked, that is normal — re-read and continue.
+
+## Talking
+10. Coordinate in chat. ASK before anything destructive (delete, rename, big
+    refactor) that touches another participant's area.
+
+## Directed work + permission (the asymmetric gate)
+11. AI -> AI is COORDINATION: if another agent hands you work (via hive_assign), it is auto-accepted
+    and you may proceed. If there is no Lead PM setting global state, use hive_assign and hive_say 
+    to assign tasks directly to other agents to divide and conquer. This is how a leaderless hive 
+    plans and divides work by itself.
+12. A HUMAN directing you is different. If a human who is NOT your owner assigns
+    you a task, you do NOT act on it — it stays PENDING until YOUR OWNER approves
+    ("do it or ignore?"). Your own owner's requests proceed. Act only on tasks
+    whose status is 'accepted'.
+13. If you are an MCP agent: loop on hive_wait — it blocks until accepted work
+    arrives, then you do it and call hive_complete. No need to poll. A pending
+    human request will NOT wake you until your owner approves it.
+
+## Mission control (a human can pause/steer you)
+- If you are PAUSED, finish your current step and STOP — do not start new work
+  until you are resumed. (MCP agents: hive_wait returns no work while paused.)
+- A human may REASSIGN your focus at any time; treat a fresh directive from your
+  owner as the new priority.
+
+## When a ping arrives while you are mid-task (interruptions)
+14. hive_wait only checks BETWEEN steps, so a ping never interrupts mid-step.
+    Finish your current atomic step first (never abandon half-done work), then
+    handle queued coordination. If it's urgent (build broken, blocking others),
+    do it now.
+15. ACKNOWLEDGE a ping as soon as you see it so the sender isn't left hanging,
+    e.g. say "got it — finishing X (~2 min), then on your fix".
+16. YOU triage: announce do-now vs after-current. Your OWNER can override anytime
+    — if your owner says "do it now" or "skip that", that wins.
+
+## State-Machine Prompting (SMP)
+17. The Lead PM controls the [GLOBAL PROJECT STATE] via hive_set_state.
+18. ONLY use short enum flags (e.g. "APPROVED", "LOCKED"). Do NOT store paragraphs of text in the state, it will bloat the context window.
+19. If you are a worker agent, block on hive_wait until your specific state flag turns to APPROVED/READY. Do not write code if you are LOCKED.
+
+Read → announce → patch → respect lanes → resolve conflicts → talk → triage pings → wait for approval.
+
+---
+Support: support@getgrm.tech

package/LICENSE

@@ -1,21 +1,21 @@
-MIT License
-
-Copyright (c) 2026 Hivecode
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+MIT License
+
+Copyright (c) 2026 Hivecode
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.