ux(steering): agents still reach for raw git worktree/read commands - find and close what pulls them off the blessed madt path #126

New issue

Closed

opened 2026-07-15 22:50:36 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-15 22:50:36 +00:00

(Migrated from codeberg.org)

Evidence from 2026-07-15 (one working session in this repo) of me repeatedly reaching for raw git despite the blessed madt_* path existing:

git worktree add x4 in a chained invocation - hook-blocked and steered to madt_worktrees (correct outcome). Root cause was a stale workflow recipe in an out-of-repo skill doc that prescribed the raw form; fixed at its source the same day, but it shows how easily prescriptive docs bypass the blessed path.
Repeated raw git -C <worktree> log/diff/show reads, each drawing the advisory FYI steer toward madt_log / madt_ref_inspect. The steers fired AFTER the fact every time; nothing surfaced the blessed read path before the first reach.
git merge-base --is-ancestor <sha> HEAD - used because NO madt_* equivalent exists for a branch-contains/ancestry check. When verifying "did that rebase actually happen" (the #125 investigation), raw git was the only tool that could answer.
The #125 mis-target itself: when the blessed path misfires or its params are unclear (rebase's dir=-not-path= targeting), the natural fallback is raw git - so every blessed-path sharp edge actively regenerates the raw-git habit the steering tries to end.

Asks

Close the primitive gaps. Audit the local git-plane READ/verify operations agents actually need around the worktree lifecycle and add the missing ones as first-class surface. Known gap from this work: ancestry/branch-contains (e.g. madt_ref_inspect action=contains ref=<sha> in=<branch> or similar) - the natural post-rebase / pre-finish verification.
Steer before, not just after. The FYI hooks teach the blessed path reactively. Where madtea owns the docs the agent reads first (madt_help topics, MCP tool descriptions, the server instructions), make the worktree lifecycle's blessed-verbs table explicit and complete so the first reach is the right one.
Keep the blessed path self-consistent - #125 (rebase targeting) is the concrete case: param conventions that differ between sibling actions of the SAME tool push callers back to raw git. Uniform targeting params across madt_worktrees actions is part of the fix.

Acceptance

The ancestry/contains check (and any other gaps the audit finds) exists on the madt surface with tests.
madt_help topic=worktrees (or equivalent) enumerates the blessed verb per lifecycle step including the read/verify steps, not just the mutating ones.
Refs #125.

Evidence from 2026-07-15 (one working session in this repo) of me repeatedly reaching for raw git despite the blessed madt_* path existing: 1. `git worktree add` x4 in a chained invocation - hook-blocked and steered to madt_worktrees (correct outcome). Root cause was a stale workflow recipe in an out-of-repo skill doc that prescribed the raw form; fixed at its source the same day, but it shows how easily prescriptive docs bypass the blessed path. 2. Repeated raw `git -C <worktree> log/diff/show` reads, each drawing the advisory FYI steer toward madt_log / madt_ref_inspect. The steers fired AFTER the fact every time; nothing surfaced the blessed read path before the first reach. 3. `git merge-base --is-ancestor <sha> HEAD` - used because NO madt_* equivalent exists for a branch-contains/ancestry check. When verifying "did that rebase actually happen" (the #125 investigation), raw git was the only tool that could answer. 4. The #125 mis-target itself: when the blessed path misfires or its params are unclear (rebase's dir=-not-path= targeting), the natural fallback is raw git - so every blessed-path sharp edge actively regenerates the raw-git habit the steering tries to end. ## Asks 1. **Close the primitive gaps.** Audit the local git-plane READ/verify operations agents actually need around the worktree lifecycle and add the missing ones as first-class surface. Known gap from this work: ancestry/branch-contains (e.g. `madt_ref_inspect action=contains ref=<sha> in=<branch>` or similar) - the natural post-rebase / pre-finish verification. 2. **Steer before, not just after.** The FYI hooks teach the blessed path reactively. Where madtea owns the docs the agent reads first (madt_help topics, MCP tool descriptions, the server instructions), make the worktree lifecycle's blessed-verbs table explicit and complete so the first reach is the right one. 3. **Keep the blessed path self-consistent** - #125 (rebase targeting) is the concrete case: param conventions that differ between sibling actions of the SAME tool push callers back to raw git. Uniform targeting params across madt_worktrees actions is part of the fix. ## Acceptance - The ancestry/contains check (and any other gaps the audit finds) exists on the madt surface with tests. - madt_help topic=worktrees (or equivalent) enumerates the blessed verb per lifecycle step including the read/verify steps, not just the mutating ones. - Refs #125.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#126

No description provided.

Rows
Columns