sixfold-space/madtea

SHA256

Fork 0

owner_repo= forge writes bypass the foreign-primary guard (ADR 0019 only reasons about dir=) #418

New issue

Open

opened 2026-08-17 15:49:38 +00:00 by hexajon · 3 comments

hexajon commented

2026-08-17 15:49:38 +00:00

Owner

The foreign-primary guard (ADR 0019, check-foreign-primary) and the local-git steering all reason about a LOCAL checkout: they resolve the target repo on disk and ask "is this a foreign primary? is it behind?". A content write carrying owner_repo= instead of dir= - madt_files create/update/delete/batch, and any forge-only write path - commits straight to the remote over the API with no local checkout in the picture, so none of those guards engage.

Concretely: an owner_repo= create onto a repo whose local clone is unborn (a fresh init, or a clone that never fetched) while the forge already carries history. The write lands on the forge, the local checkout stays empty, and the two states silently disagree. That is the exact divergence the foreign-primary posture exists to prevent, reached through the one write path that never touches a checkout. Subtler variant: an owner_repo= write onto a branch whose local clone was last reconciled long ago.

I want the owner_repo= / forge-API write path held to the same standard as dir=:

the not-behind / reconcile-before-write reasoning applied against the forge target, and
the ADR 0019 posture (do not mutate a repo whose checkout you do not own; steer to worktree plus finish) applied when an owner_repo= write targets a repo that has a local checkout the caller is not going through.

Design questions (this probably wants its own ADR, since it extends 0019):

What is the right signal for "unverified" on a pure-forge write where NO local clone exists at all? Nothing local can be stale. Refuse, warn, or allow?
Tool layer vs. a client-side PreToolUse guard: a hook can only backstop one client, so the durable fix belongs in the tool. Confirm that is the intended home.
madt_api_call raw passthrough cannot have a repo target reliably extracted from an arbitrary endpoint. Documented gap, or in scope?

Severity is moderate, because the write still takes intent. But it is a real hole in the guard set, worth closing deliberately rather than leaving owner_repo= as the unguarded write path.

The foreign-primary guard (ADR 0019, `check-foreign-primary`) and the local-git steering all reason about a LOCAL checkout: they resolve the target repo on disk and ask "is this a foreign primary? is it behind?". A content write carrying `owner_repo=` instead of `dir=` - `madt_files` create/update/delete/batch, and any forge-only write path - commits straight to the remote over the API with no local checkout in the picture, so none of those guards engage. Concretely: an `owner_repo=` create onto a repo whose local clone is unborn (a fresh `init`, or a clone that never fetched) while the forge already carries history. The write lands on the forge, the local checkout stays empty, and the two states silently disagree. That is the exact divergence the foreign-primary posture exists to prevent, reached through the one write path that never touches a checkout. Subtler variant: an `owner_repo=` write onto a branch whose local clone was last reconciled long ago. I want the `owner_repo=` / forge-API write path held to the same standard as `dir=`: - the not-behind / reconcile-before-write reasoning applied against the forge target, and - the ADR 0019 posture (do not mutate a repo whose checkout you do not own; steer to worktree plus finish) applied when an `owner_repo=` write targets a repo that has a local checkout the caller is not going through. Design questions (this probably wants its own ADR, since it extends 0019): - What is the right signal for "unverified" on a pure-forge write where NO local clone exists at all? Nothing local can be stale. Refuse, warn, or allow? - Tool layer vs. a client-side PreToolUse guard: a hook can only backstop one client, so the durable fix belongs in the tool. Confirm that is the intended home. - `madt_api_call` raw passthrough cannot have a repo target reliably extracted from an arbitrary endpoint. Documented gap, or in scope? Severity is moderate, because the write still takes intent. But it is a real hole in the guard set, worth closing deliberately rather than leaving `owner_repo=` as the unguarded write path.

hexajon added the

status/needs-decision

label

2026-08-17 15:49:38 +00:00

hexajon commented

2026-08-17 15:49:44 +00:00

Author

Owner

Where I have landed, and what is still open.

My plan: hold the owner_repo= / forge-API write path to the same reconcile-before-write standard as dir=, in the TOOL layer. A PreToolUse hook backstops only one client, so the durable fix belongs in the tool. Leave madt_api_call raw passthrough as a documented gap, because no reliable repo target can be extracted from an arbitrary endpoint. This extends ADR 0019, so it wants its own ADR.

Still open: the no-local-clone case. Nothing local can prove not-behind there, so the choice is refuse-and-require-an-explicit-confirm, or warn-and-proceed. My lean is fail closed and refuse, because that matches the rest of the guard set. The counter-argument is that a first write to a genuinely new repo is then always two steps. I want to settle this before drafting the ADR.

Where I have landed, and what is still open. My plan: hold the `owner_repo=` / forge-API write path to the same reconcile-before-write standard as `dir=`, in the TOOL layer. A PreToolUse hook backstops only one client, so the durable fix belongs in the tool. Leave `madt_api_call` raw passthrough as a documented gap, because no reliable repo target can be extracted from an arbitrary endpoint. This extends ADR 0019, so it wants its own ADR. Still open: the no-local-clone case. Nothing local can prove not-behind there, so the choice is refuse-and-require-an-explicit-confirm, or warn-and-proceed. My lean is fail closed and refuse, because that matches the rest of the guard set. The counter-argument is that a first write to a genuinely new repo is then always two steps. I want to settle this before drafting the ADR.

hexajon self-assigned this

2026-08-17 17:45:48 +00:00

hexajon commented

2026-09-08 20:02:31 +00:00

Author

Owner

Rule for a forge-API content write via owner_repo= with no reconciled local view:

Target repo empty/unborn -> allow. A create-new write has nothing to clobber, so a genuinely new repo just works, with no two-step friction.
Target repo already populated -> refuse, non-overridably. No confirm flag, no env, no git-config key widens it (ADR 0009 posture). The remedy is the sanctioned path: clone + worktree->finish, or I run it on the CLI (unguarded per ADR 0019).

The guard keys on forge truth the agent cannot fake (is the target empty or populated), not on the agent's cooperation. This is the require-remote-verified pattern (block when the forge is populated and the local view is unborn/behind), but living in madtea's tool layer so it protects every MCP client, not just one host's PreToolUse hook. It extends ADR 0019 to the forge-API write path, which today reasons only about local checkouts.

Scope note: the madt_api_call raw passthrough stays a documented gap - no reliable repo target is extractable from an arbitrary endpoint (consistent with ADR 0027 excluding the passthrough). This guard covers the typed content-write tools (madt_files, API-plane madt_commit, madt_branch_create, ...).

This warrants its own ADR extending 0019. Clearing needs-decision.

Decided: a non-overridable, tool-layer guard keyed on server-side forge state. No agent-settable confirm - an agent-flippable override is not a guard (ADR 0009). An unattended agent would just pass confirm=true and clobber, so consent cannot be the mechanism. Rule for a forge-API content write via `owner_repo=` with no reconciled local view: - Target repo empty/unborn -> allow. A create-new write has nothing to clobber, so a genuinely new repo just works, with no two-step friction. - Target repo already populated -> refuse, non-overridably. No confirm flag, no env, no git-config key widens it (ADR 0009 posture). The remedy is the sanctioned path: clone + worktree->finish, or I run it on the CLI (unguarded per ADR 0019). The guard keys on forge truth the agent cannot fake (is the target empty or populated), not on the agent's cooperation. This is the require-remote-verified pattern (block when the forge is populated and the local view is unborn/behind), but living in madtea's tool layer so it protects every MCP client, not just one host's PreToolUse hook. It extends ADR 0019 to the forge-API write path, which today reasons only about local checkouts. Scope note: the `madt_api_call` raw passthrough stays a documented gap - no reliable repo target is extractable from an arbitrary endpoint (consistent with ADR 0027 excluding the passthrough). This guard covers the typed content-write tools (`madt_files`, API-plane `madt_commit`, `madt_branch_create`, ...). This warrants its own ADR extending 0019. Clearing needs-decision.

hexajon removed the

status/needs-decision

label

2026-09-08 20:02:31 +00:00

~~hexajon referenced this issue 2026-09-08 20:04:02 +00:00~~

Investigate re-evaluating workspace scope when the MCP client adds a working directory mid-run #416

hexajon referenced this issue

2026-09-08 21:17:06 +00:00

docs(adr): record isolation and signing posture decisions (amend 0013, 0019, 0027) #471

hexajon commented

2026-09-08 21:17:39 +00:00

Author

Owner

Recorded in the design of record: ADR 0019 amendment (2026-09-08), merged in PR #471. This issue stays open for the tool-layer guard implementation (allow empty, refuse populated).

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#418

No description provided.

Rows
Columns