Skip to content
Cockpit0.29.0
A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live

I2735

An edit no claim covers is refused

Where it stands

devtask.issue
Readiness
blocked 1 of its dependencies is not DONE
Status
BLOCKED
Can start
not now
Milestone
Milestone status
PLANNED
Wave
3
Waiting on
Holds back
none
Behind it in all
0
Evidence
0 of 2
In the waySubjectDetail
issueI2289I2289 is not DONE
A move writes the repository: it stamps one field of this issue's record and appends one event to the ledger, and a commit will carry both.
The same moves from a terminal

majordomus plan start I2735

majordomus plan verify I2735

majordomus plan done I2735

What it is

Objective
With session.edits_require_claim on and the mesh enabled, a provider's pre-tool hook refuses a write (Edit, Write, MultiEdit, NotebookEdit) no claim covers: the active task's scope or a live mesh claim of the writing session; judged by majordomus guard hook in the checkout the file belongs to, and by the capability guard.edit over MCP and HTTP.
Why
On 2026-10-15 the owner asked why a session does not join the mesh and work on it, and why nothing enforces it. I2734, I2288 and I2289 put the session and the task on the mesh and refuse a completion off it; an edit nobody claimed was still never stopped, so the claim stayed a convention until the edit itself asked for one. Prior art: the unmerged branch feature/the-guard-refuses-an-unready-episode (2026-09-11) wired a PreToolUse guard for server readiness; this asks a different question, in the executable, because the hook runs before every edit and the shell tool's cold start was measured at about 4 s.
Now
No hook runs before a tool; an edit no claim covers is never refused.
Wanted
guard hook exits 2 with the path and the remedy for an unclaimed edit; the session's own live claim or the active task's scope lets it through; local state, a path outside the checkout, the policy off and a server that does not answer are let through; the tracked shim passes on 2 and nothing else.
Done when
unknown: the record declares no `completion`
Risk
unknown: the record declares no `risk`

Acceptance

  • An unclaimed edit is refused with exit 2, naming the path and the remedy
  • The writing session's live claim, or the active task's scope, lets the edit through; another session's claim does not
  • Local state, a path outside the checkout, a tool that writes no file, the policy off and an unanswering server are let through
  • The checkout judged is the one the written file belongs to
  • The tracked shim passes on the refusal and nothing else
Validation
bin/majordomus plan validatecargo test --lib guardbash test/run.sh 3069_an_edit_no_claim_covers_is_refused
Evidence required
case_3069guard_unit_tests
Evidence present
unknown: the record carries no `evidence` entries

Scope

Touches
apps/majordomus-cli/src/guard.rsapps/majordomus-cli/src/capability/builtin/guard.rsapps/majordomus-cli/src/commands/guard.rsapps/majordomus-cli/src/cli.rsapps/majordomus-cli/src/cli/local.rsapps/majordomus-cli/src/policy.rs.claude/hooks/majordomus-edit-guard.ai/repo/policy.yamlshare/schemas/majordomus/policy/policy.v1.schema.jsonshare/skeleton/policy.yamltest/cases/3069_an_edit_no_claim_covers_is_refused.shdocs/MESH.md
Not
unknown: the record declares no `non_scope`
Depends on
Priority
p0
Profile
implementation
Parallel safe
false
Owner
unknown: the record declares no `owner`

The work so far

Branches
none
Merged
none
Commits
0
Trunk
master
Sessions
none
Created
2026-10-15
Updated
2026-10-15
Started
unknown: the record declares no `started_at`
Verified
unknown: the record declares no `verified_at`
Completed
unknown: the record declares no `completed_at`

Synchronisation

Adapter
scripts/github-sync
Repository
unknown: the derived plan's header carries no repository
External issue
unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
State there
unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

Findings

Nothing is wrong with these records.