Skip to content

harflow mcp AGENTS.md changelog

io.github.harflow-dev/harflow-mcp

2 changes recorded. MCP Harbor re-reads this listing from the official registry every six hours and asks the live server what it exposes, and keeps what changed between one look and the next.

  • AGENTS.md +14 −3

    https://raw.githubusercontent.com/harflow-dev/HarflowMCP/HEAD/AGENTS.md

    − 1. **Only `_monitor` publishes a terminal status and sets `Task.done`**, after process exit and−   workflow resumes never consume.− - Lock order: session lock (or the `continuation-<root>` chain lock), then `<id>.lock` and+ 1. **Only `_monitor` publishes observed terminal settlement and sets `Task.done`**, after process exit and+    The narrow exception is `task_recovery.recover`: after durable matching owner and agent generations+    are confirmed dead under session/launch/task locks, it may CAS an unchanged running record to+    failed with an unobserved outcome and separate `interruption` evidence. It never sets `Task.done`,+    invents exit/drain evidence, emits completion notifications or schedules continuation.+   workflow resumes never consume. The separately negotiated+   `conversation_delivery_v1` ledger has a narrow exception: its settlement owner+   may issue one claimed message as a `queue_drain` response in the same native+   conversation. That route never consumes this legacy follow-up ledger and never+   substitutes a Fresh automatic continuation. Persist its destination before+   issuance; native acceptance alone is not consumption, and unknown delivery+   never authorizes replay.+ - Lock order: session lock (or the `continuation-<root>` chain lock), then the nonblocking `<id>.launch.lock`, `<id>.lock` and+ Migration work: see [docs/migration-plan.md](docs/migration-plan.md).

  • AGENTS.md +27 −3

    https://raw.githubusercontent.com/harflow-dev/HarflowMCP/HEAD/AGENTS.md

    − - On claude, `publish` drops the git denies and adds `--allowedTools`; passing both defeats itself,−   since deny beats allow.−   - **One-shot stdin must reach EOF immediately**, because codex and vibe block on an open pipe.+ - On claude, `publish` drops the git denies and adds `--allowedTools`, because the freedom's own+   allow entries would be defeated by its own denies (deny beats allow). `write_in_repo` with+   `allowed_commands` intentionally passes both: the unchanged denies stay and still win (measured), so+   no pattern can re-enable a direct `git commit` or `git push` command string there, except the exact+   merge-conclusion carve-out (`git commit --no-edit` or `git merge --continue`). That grant omits+   `Bash(git commit:*)` because deny beats allow, keeps the push deny, and is gated by Harflow's PATH+   wrapper on `MERGE_HEAD`. `direct_commit_commands_denied` is then false and `local_commit` stays+   denied. A granted program may still invoke git itself.+   - **The scratch note travels only through a measured system-prompt seam**, declared as+   `Capabilities.system_guidance` and attached by that backend's `with_system_guidance`, never as a prefix to the+   caller's prompt (a leading `/slash` command must stay first, and handoffs are verbatim). Each `assert_safe` accepts+   exactly `system_guidance.TEXT`, once, in one position; vibe and agy declare none; a failure to attach it never blocks+   a launch.+ - **One-shot stdin must reach EOF immediately**, because codex and vibe block on an open pipe.+ - The resource ledger (`resources.py`) lock is a leaf: taken last, held for one bounded read-modify-write,+   never across an `await`, a subprocess (including `ps`), Git or another lock. Waiting for resources+   happens in the detached owner holding no lock; the launch receipt is the waiting task's only state+   (no TaskRecord until spawn), and uncertainty never frees an entry.+ - Shared chain and group scratch (`shared_scratch.py`) is allocated by the launch owner under a per-folder `flock` that is a+   leaf lock (bounded poll before the pre-spawn window, held until the task record is durable, ordered after the session or+   chain lock and before `<id>.lock`; metadata updates take it too, and code already holding `<id>.lock` only tries it for+   a bounded time); cleanup renames under it and deletes outside it, and refuses while anything that may use+   the folder is unsettled, uncertain, pending, pinned or holds an artifact there. Access states (`writable`,+   `no_additional_grant`, `sandbox_read_only`) report what was granted, never what a freedom name suggests.+ - Task worktrees (`worktrees.py`) are created by the launch owner with `core.hooksPath=/dev/null`, never+   forced or removed automatically; a launch into one takes `<root>/.locks/<id>.lock` only to write its+   receipt, and `worktree-remove` is humans-only and fail-closed like takeover.