carlos / platform Public

plan: draft 3, and the rule AGENTS.md did not actually have

A second Fable review: four blockers, two of them security. One is
already fixed in 63e80cc; the rest land here.

I SAID TWICE THAT AGENTS.md CARRIED THE ANTI-FORGERY RULE. It did not —
not in draft 2, not in 6fba2b3's commit message, not anywhere in the
file. The claim was doing real work in both places, as the reason the
property was believed to be protected, and it was invented. AGENTS.md
now carries it, in the form that survives what was actually found:
`s3:PutObjectTagging` must never be in the app's Allow, AND ITS ABSENCE
IS NOT THE PROPERTY. The property is "this credential cannot put this
tag, by any route", it is asserted against a real server, and a policy
change is not done until that test has been watched to fail.

DECISION REASON 3 IS WITHDRAWN. Draft 2 called "the sweep is what ships
the policy fix" the strongest of the three. It is not a reason at all:
if the stack is not split, the fixes ship by construction on the branch
that merges. It is only true after deciding the sweep ships alone, so it
has zero weight on the split question — a consequence wearing an
argument's clothes, which is the exact thing the last review taught this
plan to stop doing. It moves to Phase 1 as a constraint. The decision
stands on two reasons now, honestly, or not at all.

PHASE 1'S CHERRY-PICK LIST WOULD HAVE LEFT THE SWEEP BRANCH RED TWICE.
6fba2b3's contract subtest fails against the sweep's own CI fixture,
which has no Deny statements (needs d848c57); and the sweep's
apiscan_test.go asserts no Deny after grant, which the unconditional
Denys break (needs d6142ac). 63e80cc is now a third. A hand-maintained
pick list is the wrong shape — reorder so the fix commits precede the
on-demand ones and advance the branch pointer over them, so nothing is
duplicated and the final rebase stops depending on patch-id dedupe.

THREE MORE TAGGING ROUTES ARE UNTESTED, each authorised as plain
s3:PutObject: CreateMultipartUpload with x-amz-tagging, CopyObject with
a REPLACE tagging directive, and a POST-policy form upload with a
tagging field — the last being the standard direct-from-browser pattern,
which is precisely what an app storing user uploads does. "By either
route" was two routes. Whether a gateway populates
s3:RequestObjectTagKeys in those handlers is the same gateway-specific
fact that already bit once.

And the enforce-Deny check does not need a deployed app either — draft
2 asked how to obtain an app credential and answered "pick one before
writing the step", which is draft 1's mistake wearing a later date. The
contract fixture mints a scoped credential against a real IAM on every
push. Including the variant that matters: a CopyObject from an infected
source, and a GET of the copy.

Smaller: the counts were stale again (57 above origin/main, 24 the
sweep); Phase 1 opened by pushing a tip it then rewrote; Phase 4's swap
to CARLOS_CLAMD_ADDR has to remove CARLOS_CLAMD_SOCKET in the same edit
or the console fatals and the adopt pass rolls back; the second ask of
Tito is not filed at all, so reason 2 is about half the wait it claims;
the walk.go citation needed its package, since appsettings.go holds a
second copy of the same refusal; and "two of the three answered" is
really "answered for MinIO, open for AWS" — the deployment actually
being planned.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PEkJh1ESqiA84quAHJV4K6