Replace finite clone/worktree boolean allowlists with the closed separate-value grammar, including Git's accepted long abbreviations and bundled short options. Keep placement operands distinct from HOME-valued sources, metadata, commit-ish values, and rule-generated --no-* flags while preserving separate-git-dir and later-command traps.
Canonicalize shell-known HOME spellings, dot aliases, and existing symlink parents before placement comparison. Expand the hermetic suite from 242 to 292 fixtures and document the requirements and review evidence.
Deliberate residuals: a future unclassified value-taking clone placement option can fail open, and a future worktree value option can shift the inferred path; defaulting it to flag grammar avoids present-day over-blocking of Git's non-enumerable boolean family. PreToolUse symlink canonicalization is non-atomic against replacement after inspection; architectural closure is tracked by #1199.
Classify git clone and worktree add operands so HOME-valued environment assignments, sources, references, templates, and metadata do not impersonate checkout destinations. Preserve both forms of clone --separate-git-dir as real placement targets and distinguish shell words, command boundaries, and redirections in the existing quote-aware normalized stream.
Deliberate fail-closed residual: unknown future Git options with a separate following word are not adjudicated as source-only. Their value remains a possible placement, so a HOME-shaped value blocks rather than silently creating a bypass. Relative destinations whose effective path depends on cwd remain out of scope in #1197.
Rounds 8 and 9 of the same class, in the two halves of one line.
The path arm required the home token to be followed by `/`. That silently
made `$HOME` itself -- the exact target the rule names -- legal: `git worktree
add $HOME` cleared a guard whose message is "this checks a repository out
under $HOME". Reachability is not theoretical; the command succeeds against an
empty home directory. Trailing `/` was then admitted, and with it every
terminator that is not whitespace: `$HOME;`, `$HOME&&`, `$HOME|`, `$HOME&`
and end-of-string all cleared, 25 shapes in all.
The fix that did not happen is worth recording, because it was mine. The brief
for this round prescribed a closed continuation class, `([^A-Za-z0-9_.-]|$)`,
on the reasoning that terminator sets are open and continuation sets are
closed. That is true of some axes and false of this one: `+ @ , : = %` all
continue a FILENAME, so `$HOME+bak/wt` and five siblings like it would have
been refused -- a new over-block traded for a closed bypass, which is not a
trade. The implementer measured the six counterexamples and declined the brief
rather than pick between two acceptance conditions that cannot both hold. They
are now permanent fixtures; a rejected over-block that nothing pins comes back.
The axis that IS closed is word termination, and it is closed by specification
rather than by anyone's imagination: POSIX fixes the unquoted metacharacter set
at space, tab, newline, and | & ; ( ) < >. So the path normalizer marks those
as an internal word boundary, in the same state machine and by the same
mechanism as the existing literal-dollar and literal-tilde markers, which is
what lets a QUOTED or escaped metacharacter stay word content: `"$HOME;bak"`
is one word and must be allowed. A raw marker byte arriving in the input is
encoded first, so input cannot forge or suppress a boundary. The home token
must now be preceded by start, `=`, or a boundary, and followed by a boundary,
`/` for a descendant, or end.
Verified by oracle rather than against the brief -- `bash -c "printf '%s' WORD"`
performs expansion and quote removal without executing, so the expected verdict
comes from the shell instead of from the reading that has now been wrong once.
Fixtures 198 -> 230; the new ones are red at both prior heads (15 failing at
4b8eba95, 21 at 3d0a882a), so they measure the change rather than passing on it.
Known and deliberately not addressed here: a checkout target that never names
$HOME at all. A relative target resolves against the cwd, and every agent seat
on this host runs with a cwd under $HOME, so `git clone URL` with no target at
all lands in $HOME and is invisible to a rule that matches home spellings.
That is a different rule -- it needs the effective cwd, which `cd` inside the
command can move -- and it is filed separately rather than becoming round ten
in this file.
The quote/escape handling added over rounds 1-6 was wired into the command
NAME reading only. The PATH reading one line below it still matched the raw
text, so every spelling the name arm had learned to see was invisible to the
checkout check: `"$HOME"/wt`, `${HOME}/wt`, `"${HOME}"/wt` and a quoted
literal home path all cleared a guard whose entire purpose is to refuse them.
An identifier is not one spelling, and this file has now proven that seven
times; the arms of the rule were audited one at a time, and the class survived
in the arm nobody looked at.
The two readings need the same quote and escape handling but differ in one
respect, so this is one state machine with two modes rather than a copy:
substitution flattening is correct for a name and wrong for a path, where an
expansion-capable `$HOME` must stay visible. In path mode a shell-LITERAL
dollar or tilde -- single-quoted, escaped, or a quoted tilde -- becomes an
internal nonmatching marker, so quote removal cannot manufacture a home
spelling the shell would never expand, and `"~/wt"` is no longer refused.
`home_re` treats the braces as the pair they are. `$HOME}` expands HOME and
appends a literal brace; `${HOME` is not an expansion at all. Admitting either
as `${HOME}` would invent a home path the shell never resolves.
Verified by oracle rather than by assertion: for each spelling, `printf` under
bash performs expansion and quote removal without executing, and the resulting
path decides the expected verdict. 24 spellings, 0 mismatched here; 6
mismatched at 3d0a882a, which is what makes this a fix and not a rewrite.
Fixtures 184 -> 198.
Round six of the same class: a program NAME is not one SPELLING. Two findings,
and the second is one this change's own predecessor introduced.
A FOURTH name consumer never went through the shared site. Checkout detection
still recognized git by a raw whole-command regex, so `g"it" clone`, `g'it'
clone` and `g\it clone` into $HOME were all allowed. `/usr/bin/git` blocked only
because the raw text still happened to contain contiguous `git` — the same
passing presentation that established nothing during the curl rounds. It now
uses CMD_NAMES and NAME_PREFIX like the other three, so all four consumers
share one definition of what a name looks like.
Routing it through NAME_PREFIX also repaired an over-block the arm had carried
from the start: the old regex found `git` INSIDE a longer word, so `mygit clone`
and `gitfoo clone` were refused at every previous head. That is the mycurl and
curl-wrapper class, and refusing it is how a guard gets routed around instead
of repaired.
The normalization itself was creating names the shell never runs. It deleted
every backslash regardless of quote context, but a backslash inside single
quotes is literal, so `'cu\rl' --config` names a program called cu\rl and was
refused. The same holds inside double quotes before any character other than
$, `, " or backslash. Both were false positives, and both were regressions —
the pre-PR head allowed them.
Quote removal and escape handling are different operations that were sharing
one context-blind deletion pass. They are now a small state machine that
follows the actual rule: outside quotes a backslash escapes the next character;
inside single quotes everything is literal; inside double quotes a backslash is
special only before $, `, " or backslash. Quote characters drop without
splitting the word, and the substitution flattening that makes `$(which curl)`
resolve to a bare name is unchanged.
An over-block is not the safe direction. A guard that refuses legitimate work
gets routed around rather than fixed, which is the same outcome as a bypass and
arrives faster.
Unchanged and still disclosed: names absent from the literal text — assembled
from braces or variables — remain invisible to text matching, and `$((curl))`
is over-matched at every head including the pre-PR one.
Fixtures: 173 -> 184. Every one added here discriminates against the previous
head 1c3e79a9 (8 fail there: 3 git bypasses, 5 over-blocks), and the positives
also fail at the pre-PR head df83a9ee. Suite green at head, bash -n and
shellcheck clean, enumeration gate 55/38/18.
Test-only. No change to the guard; every case below already behaves
correctly at 46f52eed. They are committed because reasoning that a shape was
already covered is exactly what produced rounds four and five, and an
unmeasured belief about a security control is worth nothing.
Three fail at df83a9ee and pass here, so they discriminate:
\curl --config /tmp/w.cfg escaping the leading character
cur"l" --config /tmp/w.cfg the quote at a different offset
g"h" api -X POST "repos/a/b/$EP" … both halves dressed at once
`\curl` is the ordinary way to bypass a shell alias. It is a thing people
type, which makes it the least hypothetical entry in the file, and it was
not covered by any of the eight fixtures added in the previous commit.
The last one is the case I would have bet on breaking: the name gate reads
the normalized copy while the unreadable-endpoint tail reads RAW text, so
dressing BOTH halves at once is the input where those two readings are most
likely to disagree. They do not — the tail matches through the quote — but
the previous commit's message asserted that from reading the regex rather
than running it, and one round earlier the same kind of assertion was wrong.
Four negatives pass at BOTH heads and are here as regression guards: a
quoted read, an ordinary download, `gh --version` with no api subcommand,
and the word curl inside a string with no flag. Over-blocking is a real
failure and not a safe direction — a guard that refuses legitimate work gets
routed around instead of repaired, which costs more than the bypass it was
protecting against.
Suite 173/173.
Round-five remediation of both blockers gate-ultron-01 raised on df83a9ee.
Measured against that head first; all eight returned rc=0 and each executes
the program the check exists to recognize:
cu"rl" --config /tmp/w.cfg -> allowed
cu'rl' --config /tmp/w.cfg -> allowed
/usr/bin/cu\rl --config /tmp/w.cfg -> allowed
g"h" api -X POST repos/a/b/issues … -> allowed
/usr/bin/g\h api -X POST repos/a/b/… … -> allowed
curl --con"fig" /tmp/w.cfg -> allowed
/usr/bin/gh api -X POST repos/a/b/$EP … -> allowed
g"h" api -X POST repos/a/b/$EP … -> allowed
BLOCKER 1. The previous commit said names are recognized "after quote
removal" and did not do that. It replaced quote characters with whitespace,
which is token SEPARATION: a shell removes a quote WITHOUT splitting the
word around it, so `cu"rl"` is one word naming curl, while whitespace made
it two words naming neither. `"/usr/bin/curl"` blocked under that version
only because the inserted space happened to land after a slash — a passing
case that established nothing about quote removal, and I read it as
confirmation. The characters are now DELETED, which is what quote removal
is. Backslashes go with them, because escaping is ordinary word formation
too. Deletion still handles substitution: `$(which curl)` becomes
`which curl`, where the name is a word on its own.
The flag is read from the same normalized copy for the same reason —
`--con"fig"` is one word spelling --config. No review raised that; the name
was simply the easier half to reach, and reading both halves the same way
is the entire point of having one normalization.
BLOCKER 2. A THIRD name consumer never went through the shared site: the
unreadable-endpoint arm kept a private bare-name copy of the scope gate's
regex against raw $CMD. A caller could be admitted by the repaired gate and
then go unrecognized by the fail-closed refinement — a gate and its own
refinement disagreeing about who the caller is, which is the defect one
layer downstream.
Fixing that surfaced the same mistake a third time inside this very edit:
my first version left the NAME in the refinement's tail regex, so the name
gate recognized `g"h" api` while the tail still demanded the undressed
spelling, and the two halves disagreed exactly as before. Caught by the
fixture, not by reading. Each half now asks one question: the name gate
asks WHO, from the normalized copy; the tail asks whether the ENDPOINT is
readable, from the raw text — deliberately raw, because the expansion
markers that make an endpoint unreadable are the characters the normalized
copy removes, and reading the tail from it would erase the evidence.
Controls: the 8 positive fixtures FAIL at df83a9ee and pass here; the
negatives — mycurl, curl-wrapper, mygh, mygh with an assembled endpoint, an
absolute-path read, and -K on a non-curl — pass at BOTH heads. Suite
166/166.
Unchanged and still stated in the comment rather than this message: a name
ABSENT from the text, assembled from variables or reached through a wrapper
script that execs the program, is invisible to any of this.
Round-four remediation of both blockers gate-ultron-01 raised on d99ff57e.
Measured against that head before anything was touched; all seven returned
rc=0, and each executes the program the check exists to recognize:
"/usr/bin/curl" --config /tmp/w.cfg -> allowed
'./curl' --config /tmp/w.cfg -> allowed
$(which curl) --config /tmp/w.cfg -> allowed
`which curl` --config /tmp/w.cfg -> allowed
/usr/bin/gh api -X POST repos/a/b/issues … -> allowed
./gh api -X POST repos/a/b/issues … -> allowed
/usr/local/bin/tea api -X POST repos/a/b/… … -> allowed
This is the third appearance of one defect, and the shape is worth stating
plainly because the first two repairs each fixed an INSTANCE and left the
class: the check matched the bare word, then it matched the unquoted
basename. Both were models of one TEXTUAL PRESENTATION of a shell word
rather than of the word, so the first repair was defeated by an absolute
path and the second by two quote characters. Recognizing a name is either
done after quote removal or it is caller-name parsing wearing a longer
regex.
The second blocker is the same defect sitting untouched in the API SCOPE
gate the whole time, while the curl arm was repaired twice beside it. That
one is worse than it looks: the scope gate decides whether write detection
runs AT ALL, so failing to admit `/usr/bin/gh api -X POST` is not a missed
match, it is an allow. No URL marker rescued those commands either —
provider CLI endpoints are spelled `repos/…` with no leading slash, so
`/repos/` never matched them.
Fix, and the reason it is one fix rather than two:
- $CMD_NAMES — a second reading of the same command with quote and
substitution punctuation turned into whitespace. Names are read from it.
- $NAME_PREFIX — the one place the shape of a program name is written
down. Both callers use it, so the next fix to this class lands in a
single location instead of whichever arm review happened to probe. That
is the actual lesson of finding this defect twice in one file.
The prefix still must end at a slash. `mycurl` and `curl-wrapper` are
different programs and blocking them is the over-block that gets a guard
routed around instead of repaired; both remain negative fixtures, and
`mygh` and an absolute-path READ join them.
The cost is the one this file already chose and documented for the payload
check: quoting an example does not exempt it, so writing one of these
commands inside quotes on a Bash line is refused too. Applying that rule to
the name arms makes the file coherent — the alternative is a guard where
the payload arm treats quotes as text and the name arms treat them as
armour.
Still open, stated rather than left to be found: a name absent from the
text — assembled from variables, or reached through a wrapper script that
execs the program — is invisible here. That is a limit of inspecting a
command string, not something a pattern closes.
Controls: the 7 positive fixtures FAIL at d99ff57e and pass here; the 4
negative fixtures pass at BOTH heads, so they measure over-blocking rather
than decorate the diff. Suite 157/157.
Round-three remediation of the single blocker gate-ultron-01 raised on
06046f76. Confirmed by measurement before being touched: all three spellings
returned rc=0 against that head.
/usr/bin/curl --config /tmp/provider-write.cfg -> allowed
env /usr/bin/curl -K/tmp/provider-write.cfg -> allowed
./curl --config /tmp/provider-write.cfg -> allowed
The config file still owned the URL, method, body and headers in every one of
them, so each executed exactly the wrapped raw provider write the previous
commit was written to refuse, while the guard reported clean.
The mistake is worth naming precisely, because it is the one this file already
exists to refuse and I reintroduced it: recognizing the unqualified name only is
CALLER-NAME PARSING. `/usr/bin/curl` is not a different program from `curl`, and
a control that can be defeated by typing the absolute path is not a control. The
match is now on curl as a BASENAME — an optional prefix that must end at a
slash — so a path spelling costs the caller nothing and buys them nothing.
The prefix must end at a slash deliberately: `mycurl` and `curl-wrapper` are
different programs, and blocking them would be the over-block that gets a guard
routed around instead of fixed. Both are negative fixtures.
Still open and stated rather than left to be discovered: a wrapper script that
execs curl on the operator's behalf is invisible here, because neither the name
nor the request appears in the command text. That is a limit of inspecting a
command string, not something this regex can close, and it is now written in the
comment above the check.
Controls: the three bypass fixtures FAIL against 06046f76 and pass at this head;
the two over-block fixtures pass against both. Suite 148/148.
Round-two remediation of the four blockers gate-ultron-01 raised on f8d04d1b. All
four were confirmed by my own measurement before being touched; none is taken on
the reviewer's word.
1. The --config/-K refusal never ran. It sat nested inside `if API_SHAPED`, and
API_SHAPED is a test for a provider URL in the command text — which is exactly
what a config file removes. The check was guarded by the condition that the
capability it guards against defeats, so `curl --config /tmp/write.cfg` walked
past it. It now keys on curl itself, ahead of the URL gate, and covers the
attached (`-K/tmp/f`) and bundled (`-sK`) spellings a space-separated test
cannot see.
2. Percent-encoded endpoints are a live route, not a theoretical one. Measured
against the provider: `…/issues/1174` and `…/iss%75es/1174` both return HTTP
200 for the same object. A write carrying any percent-escape is now refused
rather than decoded — a decoder has to be exactly right about depth
(%2569 -> %69 -> i) and about the provider's own normalisation, and being
approximately right there is indistinguishable from not checking. Scoped to
writes: a read is never this hook's business and a query string carrying %20
is an ordinary URL.
3. HOME was still expanded unguarded at the `W=` fallback, which runs before any
of the new HOME adjudication — so a guard deployed without its siblings still
died on an unset HOME, upstream of the fix that was supposed to survive it.
Moving a fail-open earlier in the file is not closing it. HOME is now resolved
once, above every use, and every later site reads the resolved value.
The existing harness could not have caught this: it runs the guard beside its
siblings, so `[ -x "$W/pr-review.sh" ]` always succeeded and the fallback was
never reached. A test's blind spot can be a property of the harness rather
than of the code. The new lone_case() block copies the guard alone into an
empty directory and re-asserts the four behaviours there.
4. test-mosaic-worktree-large-repo.sh shipped at mode 100644 and appeared in no
CI step, so the enumeration guard (#1017) redded pipeline 2386 — correctly.
Committed mode is now 100755 and the test is enumerated in the sanitization
step. My own process miss: I verified the CI queue before pushing and never
verified terminal CI after.
Controls: the 25 fixtures added here all FAIL against 029af418 (rc 0 or 1 where 2
is required) and all pass at this head, 143/143.
Four blockers from adversarial review, and three are one defect wearing three
hats: a test over the WHOLE command text deciding an ALLOW. That is the
fail-open shape this file keeps rediscovering, and it had reached the
break-glass itself.
- Break-glass read POSITIONALLY. `case $CMD in *MOSAIC_WRAPPER_OVERRIDE=1*)`
cleared the entire command if that string appeared anywhere in it, so quoting
the override in a note, naming a variable after it, or writing =10 disabled
the guard for the call sitting beside it. Now only leading NAME=value
assignments count, exactly where the shell would honour one. Cost, pinned as a
fixture: an override after `&&` no longer arms.
- $HOME resolved once, and unset / empty / "/" refused. This was filed as a
checkout-arm defect and is larger: under `set -u` the old file died at line 62
on EVERY command with HOME unset, exit 1, before the API arms or the APPROVE
trap ran. A seat with no HOME (systemd unit, container, env -i) had no guard at
all. A checkout whose question cannot be asked now blocks; the blast radius is
asserted to be that one command shape and not the session.
- Subresource refinement inverted. It asked whether a subresource appears
anywhere in the command, so `gh api -X PATCH .../issues/1 -f body=cf-/pulls/2/files`
was cleared on the strength of text in its own body. It now clears only when
EVERY numbered-object occurrence carries a subresource.
- -K/--config refused. curl reads the method, body, headers and URL from that
file, so none of them are in the command: every write test read 0 and the call
went through. An unreadable request is not a cleared one.
mosaic-worktree: never close a git pipe early
resolve_repo took the first porcelain line with `awk ... exit`, which closes the
read end while git is still writing. git takes SIGPIPE, pipefail returns 141, and
the function aborts SILENTLY — no message, no path, exit 141. It fires as a
function of REPO SIZE: fine on three worktrees, reliable on seventy. Measured at
73 worktrees (10 KB of porcelain): rc=141, no output. The file already removed a
`head -200` for this exact reason; the rule is now uniform.
Evidence — every new case run against 029af418, the tree before these fixes:
test-wrapper-guard.sh 130/130 pass here; 15 FAIL against 029af418
test-mosaic-worktree-large-repo.sh 2/2 pass here; 2 FAIL against 029af418
(got rc=141 and empty output, the signature)
No pre-existing fixture changed behaviour on the old guard, so the new cases are
the whole delta. The size dependence is stubbed out rather than inherited: a test
that ran against whatever repo it sits in would have PASSED on the broken tree.
The scope gate asked for a scheme URL, a `/api/v[0-9]` path, or a provider-CLI
`api` subcommand. `/api/v[0-9]` is Gitea's spelling. GitHub's API carries no
version segment at all -- `api.github.com/repos/a/b/issues` -- so the schemeless
Gitea write was in scope and the schemeless GitHub one was not:
curl -X POST -d x api.github.com/repos/a/b/issues rc 0
curl -X POST -d x api.github.com/repos/a/b/issues/1/comments rc 0
host=api.github.com; curl -X POST -d x ${host}/repos/a/b/issues rc 0
A gate calibrated to one provider's spelling rather than to what identifies a
provider API. `/repos/` is the marker both dialects share -- every forge API
addresses a repository through it -- so the gate now names both.
This is SPAN a third time, and the third layer it has appeared on. Round 8: a
block message named a wrapper that could not make the call. Round 9: a map
claimed a span its wrapper did not cover. Round 10: a control claimed a surface
it did not measure. Here the scope gate itself claimed a class of API and
recognised one member of it. Same question each time -- does this thing SPAN
what it claims -- and it has now been the answer four rounds running, which is
the argument for asking it of every arm rather than of the reported one.
Widening a scope gate can only make the guard stricter. Downstream a block still
requires a body flag AND either a mapped endpoint or an unreadable one, so this
widens what is CONSIDERED, not what is refused. The three fixtures asserting that
-- a schemeless GitHub read, an unwrapped GitHub endpoint, and a read past `--`
-- exist to hold that claim to account rather than state it.
Also: the provider-CLI arm's option scanner required a letter after the dashes,
so `gh api -X POST -- ${p}${q} -f title=x` walked its endpoint straight past.
The end-of-options marker is the one option not spelled like one, and a scanner
that skips options had to be told so.
Because the new endpoints are READABLE, each blocked fixture asserts the wrapper
its message must name. A rc-only fixture here would have passed on the unreadable
arm and proved nothing -- which is the failure mode this suite caught in itself
last round.
Evidence: 110/110 fixtures (was 101) locally and in ci-base. Negative-controlled
per change, not in aggregate: dropping `/repos/` from the gate fails exactly the
five GitHub fixtures; dropping the `--` alternative fails exactly one; neither
disturbs a pre-existing fixture. 18-command sweep unchanged (same three round-6
flips, nothing new); 12-command ordinary-work sweep 0 blocked. shellcheck clean
at warning+. CI 2374 on the previous head was green across all nine steps.
Residual, stated rather than implied: a caller who splits `/repos/` itself in a
schemeless GitHub URL leaves no literal marker anywhere and is out of scope --
the same boundary as splitting the hostname, and no longer a mistake anyone
makes by accident.
Round 11, addressing rev0 review 154.
Round-9 review found the fail-closed rule narrower than the block it guards.
The scope gate admits three shapes — a scheme URL, a schemeless /api/vN path,
and a provider CLI's `api` subcommand — but the unreadable-endpoint test asked
only for https?://. So a split endpoint token in the other two shapes was in
scope to be blocked, produced no readable endpoint, and fell through to ALLOW,
while the identical split behind a literal scheme blocked.
Four writes reaching the provider unexamined, one of them a review verdict:
p=repos/a/b/iss; q=ues; gh api -X POST ${p}${q} -f title=x
p=repos/a/b/issues/1/comm; q=ents; gh api -X POST ${p}${q} -f body=x
p=repos/a/b/pulls/1/rev; q=iews; gh api -X POST ${p}${q} -f event=APPROVED
p=/api/v1/repos/a/b/iss; q=ues; curl -X POST -d x host${p}${q}
This is the same defect class as the milestone arm one round earlier, one layer
up: there the map claimed a span its wrapper did not cover, here a control
claimed a surface it did not measure. A control is only as wide as its narrowest
arm, and widening the scope gate without widening the fail-closed rule left the
gap exactly where the gate had just been extended.
Three arms now, one per admitted shape: a scheme URL token carrying an
expansion; a schemeless token carrying both a forge fragment and an expansion,
in either order; and the endpoint argument of a provider-CLI api call, read
positionally. Limits are stated in the source rather than implied — a caller who
splits the hostname as well, and an endpoint pushed past an option whose value
contains whitespace, are both outside what this measures.
An expansion in a BODY is explicitly not unreadable. Passing a payload in a
variable is the safe practice and leaves the endpoint fully legible; blocking it
would have been a control punishing the behaviour it wants.
101/101 fixtures, up from 92. Each arm is negative-controlled separately:
removing the schemeless arm fails exactly the two schemeless fixtures, removing
the provider-CLI arm fails exactly the four CLI fixtures, and neither disturbs
any pre-existing fixture. One added fixture was rewritten after it passed for
the wrong reason — its endpoint was readable, so it blocked on the endpoint map
and never exercised the arm it was written for.
Evidence: 101/101 locally and in ci-base; shellcheck clean at warning+; a
12-command sweep of ordinary forge work — reads with split endpoints, bodies in
variables, unwrapped endpoints, an artifact PUT — blocks none of them; the
18-command sweep still blocks the same three round-six flips and nothing new.
Round eight replaced an absence-driven allow with an endpoint inventory, and
review found the inventory answered the wrong question. It recorded which
wrapper TOUCHES an endpoint, when the sound question is whether the wrapper
SPANS it. A PATCH to a numbered milestone blocked with "use milestone-close.sh".
That wrapper takes only -t <title> and sends state=closed on both the gh and tea
paths, so it cannot express a title, description or due-date edit. The block was
correct and the advice was not — the same remediation-accuracy defect as the
round-seven subresource arm, one step quieter, because a wrapper was rounded up
from owning a slice to owning the endpoint.
The treatment already existed two arms away: /pulls/{n} named pr-close.sh for
state and said in the message that a PR title/body edit is a real wrapper gap.
So this was a consistency failure rather than a missing idea, which is why the
fix is not just the reported arm. Auditing every arm for span against the flags
each script accepts found a second bad one that review had not reached:
/pulls/{n}/requested_reviewers was mapped to pr-review.sh, and pr-review.sh
takes -a <action> -c <comment> and files a verdict. Nothing in this tree adds a
requested reviewer, so that arm was advertising a wrapper that cannot make the
call. It is unowned and now flows through, like a comment edit.
Changes:
- /milestones/{n} keeps blocking, and the message states that milestone-close.sh
owns the close only while title/description/due-date is a wrapper gap.
- /pulls/{n}/requested_reviewers becomes residue, above the reviews arm so it
cannot be refused with "use pr-review.sh".
- /issues/{n} now also names issue-assign.sh, which owns the assignee field;
issue-edit.sh has no assignee flag, so the old advice was short by one wrapper
for a PATCH that sets one.
- The map comment carries a span column, so a future arm has to state what its
wrapper covers rather than imply all of it.
Fixtures assert the span language, not just the wrapper name: the milestone edit
must say it owns the close only, and a PATCH setting an assignee must name
issue-assign.sh. Negative-controlled — reverting each of the three behaviours
fails that fixture and only that fixture.
92/92 (was 89), locally and in ci-base. shellcheck clean at warning+. The
18-command ordinary sweep blocks the same three round-six flips and nothing new.
Gates: fixtures 92/92 in ci-base, shellcheck clean at warning+.
Round seven fixed "wrong wrapper advice" by letting every path under a numbered
issue or PR flow through, on the stated reasoning that no wrapper owned any of
them. Review checked that reasoning against the directory and it was false:
gh api -X PATCH repos/a/b/issues/1 -f title=x
curl -X PATCH -d @b https://host/api/v1/repos/a/b/issues/1
gh api -X PATCH repos/a/b/issues/1/labels -f labels[]=bug
gh api -X POST repos/a/b/issues/1/assignees -f assignees[]=u
issue-edit.sh takes --title/--body/--labels/--milestone and issue-assign.sh
takes assignee/labels/milestone, so all four are wrapped calls and all four
returned 0. The guard answered "allow" because wrapper ownership had been
ASSUMED absent rather than looked up — the same absence-driven allow this file
exists to remove, committed inside the fix for it. I withdraw the round-seven
departure: the reviewer's position was right on the evidence, and my argument
for it was sound reasoning applied to a fact I never checked.
The endpoint map is now an inventory read off tools/git/*.sh and their flags:
assignees to issue-assign.sh, labels to issue-edit.sh (naming issue-assign.sh
alongside it, since both set them), a numbered issue to issue-edit.sh (naming
issue-close.sh/issue-reopen.sh for state), a numbered PR to pr-close.sh (with
the PR title/body gap stated in the message rather than papered over), and
/milestones/{n} to milestone-close.sh instead of the create wrapper.
The residue is defined by SUBTRACTION, not by listing provider API surface:
everything a wrapper owns is consumed by an arm above, so a numbered path that
reaches the end is owned by nothing and still flows through — times, stopwatch,
reactions, a comment edit at /issues/comments/{id}. A list would rot the moment
a provider adds an endpoint, and rot in the blocking direction with wrong advice.
That residue test is a regex, deliberately. `case` globs cannot express a path
SEGMENT, so the natural allow arm *"/issues/"[0-9]*"/"* clears
gh api -X PATCH repos/a/b/issues/1 -f body="see /docs"
on the strength of a slash inside the body. An allow decided by a glob over the
whole command is the fail-open shape again; the regex pins the segment to the
number, and that command is pinned as a fixture.
Also: `-f labels[]=bug` was not read as a body at all, because the key class
stopped at the bracket. The array spelling is what the provider CLIs use for
repeated fields, so an implicit POST carrying only array fields was invisible.
And the reason six rounds of this were invisible: the harness read the exit code
and nothing else, so a block naming the WRONG wrapper passed every run. Fixtures
may now state the wrapper the message must name, and the wrapped ones do. The
assertion was negative-controlled — pointing one fixture at the wrong wrapper
fails that fixture and only that fixture.
89/89 (was 79), locally and in ci-base. All eight sanitization commands green
in-image. The 18-command ordinary sweep blocks the same three round-six flips
and nothing new, so the tighter map cost nothing on ordinary work.
Gates: sanitization (all eight green in ci-base), shellcheck clean at warning+.
Round six deleted the code/data parser and scoped what remained on `https?://`.
Review found the failure class had not been eliminated, only relocated: a raw
provider CLI carries no scheme, so the scope gate answered "not my business"
because the URL was ABSENT — the same shape, at the new boundary.
gh api -X POST repos/a/b/issues -f title=x -f body=y
gh api -X POST repos/a/b/pulls/1/reviews -f event=APPROVE
tea api -X POST repos/a/b/issues/1/comments -f body=x
curl -X POST -d x git.example.invalid/api/v1/repos/a/b/issues
All four were real writes to endpoints a wrapper owns, and all four passed.
Constitution gate 7 names raw provider CLIs explicitly, so they are in scope
rather than something to narrow the docs around. The scope gate now also
triggers on `/api/v{n}` and on the `api` subcommand of the provider CLIs, and
`-f key=value` joins curl's `-d` as an implicit POST. Adding triggers to a scope
gate can only make it stricter — it cannot open a new hole — which is why this
is a list of shapes rather than a model of any one caller.
The boundary is stated in the file rather than left to be discovered: provider
PORCELAIN (`tea pulls create`) is NOT covered, because catching it means
modelling every CLI's verb grammar, which is the parser mistake wearing a new
costume. That is a wrapper-and-review gap, not a thing this hook can hold.
Second finding, and the one I had flagged as my own worry: the endpoint `case`
was prefix-greedy, so `/issues/1/labels` blocked with "use issue-create.sh" —
the wrong wrapper for that call. A block an agent cannot comply with is worse
than no block, because it teaches that the hook is broken and the override is
routine, and an override that is routine is a guard that is off. Issue and PR
subresources now flow through, exactly as /releases and every other endpoint no
wrapper owns already does. This hook enforces "use the wrapper"; where there is
no wrapper it has nothing to enforce, and the gap belongs in the wrapper set.
I am departing from the review on that one deliberately: the review held that
blocking is correct there and only the remediation wrong. Naming a wrapper gap
in a refusal keeps gate-7 pressure, but it makes the override the normal path
for every labels and assignees call, which spends the override's meaning on the
cases where it is least needed.
Also: the APPROVE trap now catches the provider-CLI spelling `-f event=APPROVE`
alongside the JSON body, and still never matches the correct value APPROVED.
79/79 fixtures, locally and inside the CI image, with both blockers pinned in
both directions — the four repros block and name the right wrapper, while a
provider-CLI read, an unwrapped endpoint reached through one, porcelain, and the
`rm -f`/`grep -f` collisions all still pass. The 18-command ordinary sweep
blocks the same three round-six flips and nothing new, so the broader gate cost
nothing on ordinary work. Second over-block documented rather than found: prose
carrying `.post(` near a wrapped URL is refused, which follows from judging the
payload and is now stated next to the quoted-curl cost.
Gates: sanitization (all eight commands green in ci-base), shellcheck clean.
Round-five review found command substitution executing inside the very quoted
spans the skeleton was discarding as prose:
echo "$(curl -d@b .../issues/1/comments)"
msg="$(curl -d@b .../issues/1/comments)"
The unquoted and process-substitution forms already blocked, so the same call
was refused or allowed depending on a quote character. That makes it a
classification defect rather than another spelling, and it is the nineteenth
write to reach execution through this file by the same route: the client was
ABSENT from the skeleton, so the guard allowed.
The reviewer's judgement, which I asked for and accept: this is fitting to the
test set. Answering "code or data" from shell text with sed and awk is not a
hard problem, it is the wrong problem.
It was also not portable. CI has been red at `sanitization` since round four,
and the log says why: under the image's busybox awk the octal escape in the
quote-stripping regex does not bite, every quoted span survives into the
skeleton, and the guard began refusing ordinary prose. Five allow-direction
fixtures failed in CI that pass under GNU awk. A control that reverses its
verdict with the awk on the host is not a control.
So the client detection is gone — the skeleton, the invoker list, the prefix
list, the option-value skipping, all of it. What remains asks two questions of
the text: is this a write, and does it name an endpoint a wrapper owns. It
cannot fail open by hiding the caller because it never looks for one, and it
now catches clients it was never taught: `python -c ... requests.post(...)` and
`wget --post-data` are both fixtures.
The cost is stated in the file and pinned in both directions: QUOTING one of
these calls on a Bash command line is refused as well. Ten fixtures that used
to assert "discussing a call is not making one" now assert the opposite, and
the boundary that stops this becoming block-everything is asserted just as
hard — a quoted READ, an endpoint named without a body flag, a quoted write to
an UNWRAPPED endpoint, and the wrapper's own body flag all still pass. The
18-command ordinary-work sweep blocks none.
The rule an agent can hold without a parser: do not put a raw write to a
wrapped forge endpoint on a Bash command line, not even inside quotes. Write
the example with a file-writing tool.
60/60 fixtures, verified inside the CI image (busybox) as well as locally.
Gates: sanitization, resident budget, test enumeration, tools-index (self-test
4/4, git suite 100%), issue-close, prettier.
Round-four review, three more absence-driven allows.
1. The guard read the command as TYPED. A backslash before a newline is removed
before anything else happens, so an endpoint token split across the join
(`.../iss\` + newline + `ues/1/comments`) executed the comments endpoint while
the literal token never appeared in the text. Continuations are now joined
before every check, because the joined form IS the command. This is the same
defect as the split-across-variables case, minus the excuse: there the token
genuinely does not exist until the shell expands it, here it was sitting in
the input the whole time and the guard chose the wrong reading of it.
2. Transparent prefixes take option VALUES. `sudo -u root curl` hid a live write
because `root` was a word the prefix list did not know. Enumerating option
grammars per prefix is the wrong game, so what is skipped is an option and at
most one value for it, plus a bare duration for `timeout` — never an
arbitrary word. `xargs echo curl ...` therefore stays ALLOWED, because there
the command is echo and the client is its argument.
3. `find -exec` runs the client. It opens command position the same way an
operator does, and now reads that way.
All seven reviewer repros are fixtures, each with its counter-case in the
allowed direction: a continuation inside a heredoc document stays a document,
`xargs echo curl` stays allowed, `sudo apt-get install curl` stays allowed, a
prefixed READ stays allowed. 48/48, and the 18-command ordinary sweep still
blocks none.
Gates: sanitization, resident budget, test enumeration, tools-index (self-test
4/4, git suite 100%), prettier.
Round-three review found two more absence-driven allows, both in the skeleton
introduced by round two, and fixing them exposed a third the reviewer had not
reached yet.
1. A word in front of a command does not displace the command. `env VAR=v curl`,
`command curl`, `timeout 10 curl` and `/usr/bin/curl` were all real writes at
execution position that a bare-name match could not see. The `env` form is the
one that matters: it is what an agent reaches for to keep a credential out of
the global environment, so the careful spelling was the invisible one.
2. Quoted data stops being data when a shell is about to execute it, and the
first version knew only `bash -c`, `sh <<` and `eval`. It did not know the
pipe, which is the form people actually use: `printf ... | sh`, `cat <<EOF | sh`,
`sh -s <<EOF` each made a live call vanish from the skeleton while still
running.
3. Found while testing the fix: that decision was made for the WHOLE command, so
a single unrelated `docker run ... sh -c 'echo hi'` promoted every other
quoted span on every other line to code. It blocked its own author for the
second time in a day. A shell on one line does not execute a string on another
line, and over-blocking is not the safe direction — a guard that blocks
ordinary work gets switched off, and a guard that is off permits everything.
The skeleton is now built per line, and a heredoc body is code only when the
line that opened it fed a shell.
All seven reviewer repros are pinned as fixtures, each with a counter-fixture in
the allowed direction: `echo timeout 10 curl ...` is not a call, a pipe to `wc`
is not execution, an unrelated shell on another line changes nothing. Fixtures
40/40, and a sweep of 18 ordinary commands blocks none of them.
Gates: sanitization, resident budget, test enumeration, tools-index (self-test
4/4, git suite 100%), prettier.
The position test added an hour ago blocked its own author. The message being
sent quoted one of the fixtures, so the quoted text contained an operator
followed by a client, and an operator inside a string is not an operator. That
is the reported over-blocking defect one level in, and it landed within an hour
of shipping the fix for the reported one — which is the argument for pinning
both directions as fixtures rather than reasoning about them.
Position is now judged against a SKELETON: the command with its data spans
(quoted strings, heredoc bodies) removed. Endpoint, URL and body detection keep
running against the full text, because real calls quote their URLs and a
skeleton would be blind to them.
The exception is what makes quotes data in the first place. If something is
about to EXECUTE the quoted text — `bash -c`, `sh <<EOF`, `eval` — the quotes
hold code, and the skeleton keeps them as command separators so the client
inside is still at command position, one interpreter down.
Three fixtures: an operator inside a quoted string, a heredoc body, and
`bash -c` making the same text code again. 30/30.
Round two of the same independent review. Three findings, all real, and the
first two share a root cause: the guard was reading command TEXT as though it
were a command.
1. Splitting the endpoint token itself defeats fragment matching outright —
`a=/api/v1/repos/o/r/iss; b=ues/1/comments` leaves no fragment contiguous.
Round one fixed one spelling of this and the reviewer produced the general
form immediately. It is not winnable by more fragments: the endpoint does
not exist until the shell expands it, and this hook runs first. So the guard
stops pretending to read it. A write whose URL contains an expansion, on a
visibly forge-shaped command, is now BLOCKED as unreadable — because "I
could not find an endpoint" must not mean "there is no endpoint". Opaque
URLs that are not forge-shaped (webhooks, artifact stores) still pass.
2. The broadened body detection false-blocked ordinary work: `grep -R "curl -d
https://.../issues" docs/`, `echo "curl -d ..." > note.txt`, printing an
example from python. Talking about a call is not making one, and this is the
direction that actually kills a control — an over-blocking hook gets turned
off, and an off hook permits everything. The client must now appear at
COMMAND POSITION: line start or after a shell operator, optionally behind
VAR=value. In every false positive it sat behind a quote instead. Quotes are
deliberately NOT stripped before matching; real calls quote their URLs.
3. `wt_precious()` aborted `cmd_rm` under `set -euo pipefail`: `grep -v` exits 1
when it filters everything out, which is exactly the disposable-only case,
so a SAFE worktree failed to remove with no message. Fixed, and the same
defect was latent one step upstream in `wt_dirty()`, where `head -200`
SIGPIPEs git on any worktree with 201 changed files. The cap is gone —
counting is cheap and the cap only ever truncated output that is no longer
printed.
Seven new fixtures pin all of it, in both directions. 27/27.
An independent reviewer broke all three new controls before they shipped.
Every finding is reproduced as a fixture or a repro, because the class is
recurring rather than incidental: each hole was a case where the answer was
"allow" because something was ABSENT rather than because it was CHECKED.
1. wrapper-guard read only the spellings it knew. `curl -d@body` (no space),
`--request=POST` (equals form), and a URL path assembled from shell
variables each carried a real provider write straight through. Write
detection now covers every body and method form curl accepts, and the
endpoint match no longer anchors on a literal host path that a variable
can dissolve.
2. wrapper-guard blocked only when the wrapper FILE existed. A host with a
broken or partial install therefore permitted exactly the raw writes the
guard exists to stop. Blocking is now on the endpoint; a missing wrapper
changes the remedy text, not the verdict — a broken install is not
permission to bypass gate 7.
3. mosaic-worktree read a worktree's safety from two questions, and a clean,
fully-pushed tree holding a gitignored `local.secret` answered both with
zero. `git worktree remove` then deleted the one copy in existence. A file
is gitignored precisely so nothing else holds it, so ignored-but-not-
disposable files are now a third evidence question. Build junk
(node_modules, .venv, dist, caches, *.pyc) stays disposable, so the common
case still reads SAFE.
4. check-tools-index counted a documented tool as discoverable at mode 0644.
Every caller tests `[ -x ]`, so a non-executable tool is a missing tool;
it now fails the gate with its own message.
Local gates green: sanitization, resident budget, test enumeration,
tools-index (4/4 self-test, 100% on the enforced git suite), and
wrapper-guard 20/20.
Two defects found by running the guard rather than reading it.
1. The guard resolved its sibling wrappers through a hardcoded
$HOME/.config/mosaic/tools/git. On a host with no installed mosaic home — a
CI container, a bare checkout — every wrapper lookup missed, `[ -x ]` failed,
and the guard fell through allowing the raw API write it exists to block. It
failed OPEN, silently, in exactly the environment least likely to notice.
It now resolves relative to its own path, so it names the wrappers from the
install it was launched from, with $HOME as the fallback.
2. There was no test. Adding one surfaced the guard's other sharp edge
immediately: it matches the literal text of the Bash command, so a harness
that embeds a blocked pattern inline trips the guard on itself rather than on
the fixture. That is the correct fail-closed posture and it is now recorded in
the test's own comments, because the next person will hit it too.
test-wrapper-guard.sh asserts twelve fixtures and asserts the ALLOWED cases as
hard as the blocked ones. A guard that over-blocks gets routed around and a guard
that under-blocks is decoration; only pinning both edges keeps it useful. It is
hermetic — no network, no credentials, no repository — so it joins the CI
sanitization step directly rather than the exclusions file.
An undocumented tool is, from inside an agent session, indistinguishable from a
tool that was never written. The framework shipped 26 git wrappers and named 6 of
them in its resident index docs — 23% discoverability, with pr-review.sh among the
missing. The observable consequence was an agent obeying Constitution gate 7 as
best it could see it, reaching for raw curl, sending GitHub's APPROVE to a Gitea
host, and getting HTTP 200 with the review silently filed PENDING. Three times.
That is not a discipline failure and no amount of prose fixes it.
Four changes, each converting a rule that decayed into a mechanism that cannot:
- check-tools-index.sh (new, CI-blocking): every tool in an enforced suite must be
named in a resident index doc, and every tool an index names must exist. The git
suite is enforced now; other suites report coverage without failing, so the
ratchet tightens one reviewed PR at a time instead of landing as one sweep. The
enforced list is framework-owned rather than a marker inside operator-owned
TOOLS.md — a doc marker would let an operator silence the gate on exactly the
host where it matters most. Carries --self-test, because a checker that only
ever passes is indistinguishable from one that is not running.
- TOOLS-REFERENCE.md: complete 28-entry git index, plus the APPROVED/APPROVE
dialect note that explains why pr-review.sh is not a formality.
- mosaic-worktree.sh + wrapper-guard.sh (upstreamed): the rule "big work goes on a
work filesystem" already existed in prose, and 255 GB accumulated in $HOME across
842 directories anyway, under five simultaneous placement conventions on one
host. The helper therefore exposes no placement decision — given a branch name,
every path is derived from `git worktree list --porcelain`. Worktrees rather than
clones because enumerability is the only thing that makes reclaim safe, and
reclaim is by evidence (clean tree + no unpushed commits), never by size or age.
The guard blocks three mechanically-detectable mistakes and nothing else:
a checkout into $HOME, a raw provider-API write to an endpoint that has a
wrapper, and the literal APPROVE event. Reads pass untouched.
- STANDARDS.md: model tiering as a standard, named by capability class so it
survives a model generation. Start cheapest, escalate on evidence, benchmark
before demoting a task class, and keep the class->model binding in operator
config with the DB-backed config service as the end state.
Registering the guard in runtime/claude/settings.json is the point of upstreaming
it: ~/.claude/settings.json is a framework-managed copy, so a hand-added hook there
is destroyed by the next upgrade. In the template it survives, and it reaches every
host instead of one.
issue-comment.sh and pr-review.sh verify a durable write by pinning the
provider-returned object URL's origin and full path. The origin included the
SCHEME verbatim. On a Gitea whose ROOT_URL is configured `http://` while every
client reaches it over `https://`, the provider returns `http://` object URLs,
so the comparison rejects the provider's own truthful answer about a write that
LANDED. The failure is deterministic, not intermittent: every comment, every
time, on such a deployment.
The scheme was never what the check defends. The forgeries it exists to catch —
look-alike host, decoy path prefix, wrong owner/repo/kind/number — all vary the
HOST or the PATH. Both stay strict. `http` and `https` now collapse to one
scheme class; any other scheme (file:, ftp:, javascript:) stays distinguishing,
and an EXPLICIT non-default port still distinguishes, because a different port
is a different service on the same host.
Consequences of the bug, both observed:
- The wrapper reports failure on a comment that is durably on the issue/PR, and
attributes it to #865 ("no durable comment created"). The write landed; the
citation is wrong. Reproduced here: the harness's persisted state contains the
record while the wrapper exits 1.
- pr-review.sh's comment path is worse. On a host where no seat can create a
review OBJECT, comment-form is the only gate-16 review record obtainable, and
this check refuses all of it.
Test gap this closes: every URL fixture in both harnesses was `https://`, and
every negative case varied only host or path. The one axis that fails in
production had zero coverage — the fixtures encoded the assumption that breaks.
Added, in both suites:
- scheme-downgrade (http vs https, otherwise correct) — must be ACCEPTED. Fails
against the unmodified wrappers, passes against the fixed ones; verified in
both directions, and the negative control's captured output is the #865
misattribution above.
- explicit non-default port (`:8443`) — must stay REJECTED.
- non-web scheme (`ftp://`) — must stay REJECTED.
Also fixes test-issue-comment-readback.sh hermeticity (#1007), without which the
suite cannot run on any seat that has a per-agent Gitea token: detect-platform's
step-0 identity lookup reads ~/.config/mosaic/gitea-tokens/<identity>, outside
both XDG_CONFIG_HOME and MOSAIC_CREDENTIALS_FILE, so the suite resolved a
PRODUCTION credential and died at HTTP 401 before case 1. Same two-part fix
already merged for test-pr-review-gitea-comment.sh in #1006: a sandboxed HOME
plus an empty REPO-LOCAL mosaic.gitIdentity to shadow the global. Note the
env-var route does NOT work — detect-platform.sh reads `${MOSAIC_GIT_IDENTITY:-}`
and `:-` treats set-but-empty identically to unset.
The owner-side half of #991 (setting the deployment's Gitea ROOT_URL to https)
is not in scope here and is not made unnecessary by this change; this makes the
wrappers correct against a deployment that returns either scheme.
My previous commit said four. It is five. `test-issue-comment-readback.sh` has
the same defect and is fixed the same way, and I had already looked straight at
it and filed it as an *unrelated* silent failure. Correcting that here rather
than folding it in quietly.
WHY IT WAS MISSED — the general lesson, not the excuse. `run_comment()` sends
the wrapper's stdout AND stderr to `$OUTPUT_FILE`, and the `EXIT` trap deletes
`$WORK_DIR`. The suite therefore exits 1 with ZERO bytes on stdout and stderr,
and the one line that says what went wrong —
Error: Gitea authenticated-identity read failed with HTTP 401
— lives only inside a directory that no longer exists when anyone looks. Every
oracle I had swept the family with greps for a SYMPTOM in surviving output, so
against this suite all of them returned "nothing found", which I read as "clean"
in the first sweep and as "unrelated pre-existing failure" in the second. A
suite that discards or deletes its own evidence converts a post-hoc assay into a
non-measurement, and I wrote that sentence into the previous commit while it was
already false about a file in the same directory.
HOW IT WAS ACTUALLY FOUND. Intercept the identity read at its SOURCE instead of
grepping for its consequence: a PATH shim over `git` that logs every
`mosaic.gitIdentity` read — args, rc, and resolved value — to a file OUTSIDE any
suite's work dir, then execs the real git. Deletion-proof by construction, and
it measures the defect's cause rather than one of its symptoms. Sweeping all 16
suites with it under an ordinary invocation:
resolves a REAL identity (`mos-dt-0`) before the fix:
test-issue-comment-readback 1 read rc=1 (RED on every seat)
test-pr-review-repo-host-override 6 reads rc=0
test-ci-queue-wait-branch-absent 3 reads rc=0
the four fixed in the previous commit now read empty; the rest never read at all.
The latter two are NOT affected and are deliberately left alone: under a seat
replica (identity set, no per-slot token) neither reaches `get_gitea_token`'s
fail-loud branch, and under a canary HOME neither carries the canary credential
into any surviving artifact. They read the identity and never enter a credential
path. That residual is structural and belongs to the wrapper half of #1007 —
scoping the read with `git -C "$repo"` removes it for everyone at once.
An earlier version of that sweep reported the four fixed suites as still
resolving a real identity. That was my grep, not the suites: `value=\[..*\]` is
satisfied by `value=[] args=[…]`, because `.*` runs past the empty pair and
matches the closing bracket of the NEXT one. `value=\[[^]]` is the correct test.
Recorded because the wrong pattern failed in the direction that would have sent
me re-fixing four already-correct files.
VERIFICATION of this suite, four HOME arms, all rc=0 with zero non-empty
identity reads and the pass line on stdout: real HOME, seat replica, canary
HOME, and an empty HOME with no identity at all. Full 16-suite sweep after the
change: every suite rc=0.
CONSEQUENCE FOR THE FINDING LIST IN THE PREVIOUS COMMIT: item 2 there — the
"silently red, unrelated to #1007" suite — is withdrawn. It was #1007 all along.
Item 1 (`pr-metadata.sh:89-92`, the anonymous fallback that reports an HTTP 200
carrying valid JSON as "unknown API error") stands and is still unfixed here.
Refs #1007
CENSUS CORRECTION: FOUR suites, not the three my own #1007 audit named. The
fourth (test-pr-metadata-gitea.sh) was outside the candidate set that audit
worked from and was found only by sweeping the discriminator across all 16
tools/git/test-*.sh suites. Recording that as a correction to my finding, not
as part of the original claim.
THE DEFECT. get_gitea_token() (detect-platform.sh:502-599) resolves a per-agent
identity at STEP 0, from `git config --get mosaic.gitIdentity`, BEFORE both the
Mosaic credential loader (step 1) and the GITEA_TOKEN env check (step 2). On a
provisioned agent seat that value is set GLOBALLY in ~/.gitconfig and is
inherited by any freshly-`git init`ed repo, so step 0 reads a REAL per-slot
token out of $HOME and returns it without ever consulting the suite's own
MOSAIC_CREDENTIALS_FILE / GITEA_TOKEN fixtures. The suites were running against
production credentials, and the fixture credential each one carefully
constructs was inert.
THE FIX: an empty repo-local `mosaic.gitIdentity`. An empty local value shadows
the global one and reads back empty at rc=0, so step 0 declines. The env route
does NOT work: detect-platform.sh reads "${MOSAIC_GIT_IDENTITY:-}", and `:-`
treats set-but-empty identically to unset.
OPERATIVE vs CONTAINMENT — the two mechanisms are not interchangeable and the
comment in each suite says so. The pin is operative: it prevents the resolution.
The sandboxed HOME each suite now also gets is containment: it bounds a failure
the pin should already have prevented. Conflating them is how this class stays
invisible, because a decoy HOME REMOVES the trigger (~/.gitconfig is where the
global identity lives), so any suite audited under one reads clean however
vulnerable it is. To MEASURE, replicate a seat: a decoy HOME whose .gitconfig
sets mosaic.gitIdentity with no per-slot token, so step 0 reaches its fail-loud
branch. That note is in each file for the next auditor.
SECOND, INDEPENDENT DEFECT in test-pr-metadata-gitea.sh. Applying the pin alone
turned that suite RED — and a control at baseline 826a8b3 under a plain HOME
reproduced the same failure, so it is pre-existing, not introduced. Its
`GITEA_TOKEN="stub-token"` / `GITEA_URL="https://git.example.test"` pair can
never satisfy step 2, because step 2 accepts GITEA_TOKEN only when GITEA_URL
matches the remote host and this repo's origin is git.uscllc.com. The suite had
therefore only ever passed by resolving a REAL credential — step 0 on a seat, or
step 1 from the operator's own credentials.json. A MOSAIC_CREDENTIALS_FILE
fixture is added rather than leaning on the sandboxed HOME making step 1 find
nothing: a test that passes because production configuration is ABSENT fails the
moment it is present. Shipping the pin without this would have moved the failure
rather than removed it.
NO CI ARM. .woodpecker/ci.yml does not run these suites; packages/mosaic/
package.json:28 (test:framework-shell) runs an ENUMERATED list that excludes all
four. They run only by hand — i.e. exclusively on a provisioned seat, the one
environment where the defect is live. "Passes in CI, fails on a seat" does not
apply here; there is no CI observation at all.
VERIFICATION (seat replica = decoy HOME with mosaic.gitIdentity set, no per-slot
token; canary = same plus a marked non-credential at both per-slot paths; plain
= empty HOME; real = ordinary invocation):
- bash -n clean on all four.
- Sweep of all 16 suites at baseline 826a8b3 under the seat replica:
test-gitea-login-resolution rc=1 REACHES-STEP0; test-issue-create-
interactive-auth rc=1 REACHES-STEP0; test-pr-merge-gitea-empty-uid rc=1
REACHES-STEP0; test-pr-metadata-gitea rc=1 REACHES-STEP0.
- Same sweep after: every row rc=0 with step0 absent.
- test-gitea-token-identity flags REACHES-STEP0 in BOTH arms and is NOT a
defect: it runs under `env -i HOME="$FAKE_HOME"` (line 77) and its hit is
its own deliberate assert_failloud fixtures (lines 158-171). The fail-loud
grep matches the intended behaviour as well as the defect, so it needs the
second discriminator; recorded here so the next sweep does not re-file it.
- Durable-argv assay (a PATH shim that tees argv out of each suite's own mock
curl, because test-pr-merge-gitea-empty-uid truncates its log between phases
and its EXIT trap removes the sandbox — a post-hoc read of that suite is a
non-measurement, and "no trace" there is not a clearance):
test-pr-merge-gitea-empty-uid before: canary token in argv, fixture never
used. after: fixture token in argv, canary absent. 5 curl calls both arms.
test-pr-metadata-gitea before: canary in argv. after: both calls
carry the fixture token against git.uscllc.com.
- test-pr-metadata-gitea across seat/canary/plain HOMEs after the fix: rc=0,
rc=0, rc=0.
- All four under the real HOME: rc=0. No regression to ordinary invocation.
The comment block is duplicated across the four files rather than pointing at a
shared note. Deliberate, and matching the merged #1006 precedent
(test-pr-review-gitea-comment.sh:87-95): the reader who needs it is auditing one
file.
TWO FINDINGS DELIBERATELY NOT FIXED HERE (out of this branch's scope, to be
filed):
1. pr-metadata.sh:89-92 — the anonymous curl fallback does not check ^2, so an
HTTP 200 carrying valid JSON is reported as "unknown API error" at rc=1.
2. test-issue-comment-readback.sh exits 1 with ZERO bytes on stdout AND
stderr, dying at its first seed_state python3 heredoc. Reproduces at
baseline 826a8b3 under both a seat replica and the real HOME. Silently red
at main for everyone; unrelated to #1007.
Refs #1007
Closes#953.
GATE RECORD: review CLEAR at this exact head (author != reviewer, pre-registered diff-blind checks) + terminal-green CI at this exact head + queue guard clear.
CI CAVEAT (#973): green on the wake suites is currently WEAKER THAN IT LOOKS, IN BOTH DIRECTIONS. grep error/spawn exit codes are read as absence across 257 assertion sites in six idiom forms; 36 inverted (&&-fail) sites — including 19 credential-security canaries — fail toward GREEN under load. These greens were obtained on solo reruns after load-correlated FALSE reds (2115/2116/2118; main itself was red). This merge's safety therefore rests on the CONTENT review, not on the green. Remediation charter fa551c2d0 is authored and in flight.
Co-authored-by: mos-dt-0 <[email protected]>
Closes#952.
GATE RECORD: review CLEAR at this exact head (author != reviewer, pre-registered diff-blind checks) + terminal-green CI at this exact head + queue guard clear.
CI CAVEAT (#973): green on the wake suites is currently WEAKER THAN IT LOOKS, IN BOTH DIRECTIONS. grep error/spawn exit codes are read as absence across 257 assertion sites in six idiom forms; 36 inverted (&&-fail) sites — including 19 credential-security canaries — fail toward GREEN under load. These greens were obtained on solo reruns after load-correlated FALSE reds (2115/2116/2118; main itself was red). This merge's safety therefore rests on the CONTENT review, not on the green. Remediation charter fa551c2d0 is authored and in flight.
Co-authored-by: mos-dt-0 <[email protected]>
Closes#958.
The preimage definition (source-adapter.sh) is the single most consequential file in the wake pipeline — every observed_hash is a sha256 of what it emits — and it was UNVERSIONED: no git history, no backup. When it was edited at 07:27 on 2026-07-30, attribution was recoverable only because an agent transcript happened to still be on disk. A11 gives that file durable provenance (option (2) of #958: recorded content-addressed, not in-band).
DESIGN, per the pre-registration:
- Provenance is OUT-OF-BAND (never on the adapter's stdout) — an in-band record would advance observed_hash for every source at once and manufacture the re-baseline it exists to explain (B3).
- The obligation never depends on the provenance path: a missing/corrupt store cannot halt the detector or swallow a wake (#940 advisory-fields precedent; B4).
- DESC_FMT=d1 is NOT the provenance record — the tag versions the descriptor FORMAT; a behaviour change that keeps descriptor shape re-baselines every hash and leaves the tag unchanged (B6).
CREDENTIAL HARD GATE (rebuilt after the first verdict FAILED it): byte capture is now RECORD-ONLY BY DEFAULT (extras opt in via WAKE_PREIMAGE_CAPTURE), not allow-by-default-refuse-on-shape — because a shape list can only refuse the secrets someone already enumerated, and the tool's own usage text recommended adding detector.env (where HMAC material lives). Deny is evaluated on BOTH raw and resolved path forms with resolved anchors, ordered before allow — closing the realpath-before-deny ordering defect that let a renamed symlink target through.
VERIFICATION (reviewer, mos-dt, independent of the author's claims):
- Seven decoy cases by planted-marker-then-grep-whole-state-dir: known cred path / same-name symlink / RENAMED-target symlink / prefixed secret / prefixless secret / opted-in-symlink-to-DENIED-target all REFUSED; opted-in-symlink-to-ALLOWED-target CAPTURED (positive control that the harness can capture at all, and that C was not closed by breaking every symlink).
- Polarity-completeness self-test RE-RUN with the shape list stubbed always-allow AND both deny lists stubbed — case D still safe: the flip is complete, the shape list is not load-bearing. Each stub proven live first (a stub that silently fails to apply reports the dangerous state as safe).
- B11: rm-then-change fails LOUD (rc=1), refuses to re-baseline, leaves the ledger absent; absent-with-emptied-objects still first-installs cleanly (absent-is-not-corrupt not paid for by breaking first install).
- RED-first reproduced exactly P13-P16 pre-fix; each refusal corroborated three ways (loud stderr, ledger row captured:false WITH a hash so attribution survives refusal, objects/ holding only the adapter).
KNOWN RESIDUAL (filed #969, non-gating): the deny check is both-forms but the suite needles only the resolved form — a deny reduced to resolved-only survives 17/17 green and would leak a renamed-symlink case. No reachable leak at this head (shipped code correct on all seven decoys); it constrains a FUTURE edit. Doctrine: a both-forms fix needs a needle per form; a fixture that satisfies its assertion through a DIFFERENT rule is testing the rule it did not mean to test.
Authored by pepper (sb-it-1-dt); independently reviewed by mos-dt (sb-it-1-dt) under diff-blind pre-registration (7242688b1, predating first read) — NOT CLEAR on the first verdict (B2/B11 failed by decoy), CLEAR at 8aff7d8 after the polarity rebuild. Manifest version 0.7.0.
Co-authored-by: mos-dt-0 <[email protected]>
Closes#946.
The digest omitted a quarantined entry's claim from disclosure while still advancing the ack watermark it instructed the consumer to run — converting a fail-safe HOLD into a silent DISCARD, through the documented normal path. Measured: the burial instruction was re-issued FIVE times, four fresh digests plus one system-initiated redelivery fired purely because the entry had gone unconsumed for 1826s. That redelivery is the proof of the 'indefinitely' half: the mechanism re-asserted itself with no new information.
SCOPE — this was NOT a missing check in the consume path. Measured before the fix: dead-letter occurrences were digest.sh 27, store.sh 0, ack.sh 0, detector.sh 0, reconcile.sh 0. Quarantine was owned ENTIRELY by the renderer; the store that advances the watermark had zero knowledge the ledger existed, so an entry could be quarantined by one subsystem and consumed by another with no possible interaction. The fix is therefore a deliberate cross-module decision — option (b), quarantine recorded into a store-owned file, preserving the existing direction of dependency — pre-registered by the consumer before any diff existed.
VERIFICATION
- Pipeline 2107 terminal SUCCESS at e11bc6622, read clone-inclusive from the provider API rather than through `pipeline-status.sh` (which filters `.type != "clone"` per workflow and would hide a clone failure behind an all-green table): 9/9 children success, exit 0 each, no non-success member. Its `test` step runs all nine wake harnesses via turbo -> packages/mosaic `test` -> `test:framework-shell`.
- Independent review by the consumer on the affected lane: eleven pre-registered acceptance checks, authored and delivered BEFORE the diff was read — the file list deliberately unlooked-at, because a filename alone would have disclosed which option was chosen. All eleven resolved, no blocker.
- The check that decides it: a RAW `ack.sh consumed --upto N` with no digest involved must refuse to advance past a quarantined seq — the case an agent hits when a digest is MISSED, and the one that would have sunk a disclosure-only fix. Covered at the head as a named assertion (T13 ordinary-path bypass), written independently of the reviewer's list.
- Mutation: one asserted site disabled -> TWELVE assertions die, every one BEHAVIOURAL, ZERO count assertions, including one killing across the module boundary the fix spans.
- RED control at base a6b5f6a: 34 and 10 assertions fail, matching the body exactly.
- Coordinator re-verify by a different instrument than the reviewer used: static reference counts across the base/head boundary — store.sh 0 -> 49, ack.sh 0 -> 6, `--agent` unchanged at 4 (so #949 correctly stayed out). A fix present-but-inert passes the count and fails the mutation; a fix behaviourally correct but smuggling #949 passes the mutation and fails the count. Neither result is reachable by repeating the other.
KNOWN RESIDUALS
- The `consumed-hashes` repair criterion is met only for keys that RE-EMIT. A corrupted row whose key never recurs stays false indefinitely; the sweep covers those, and the known-false row named in the acceptance criteria had already self-healed by re-emission rather than by design — safe by population, not by design.
- The audit's clean-sweep message names one unprovable class; a second exists (a surviving dead-letter row with an empty `observed_hash` cannot be convicted either). Wording, not logic. Filed separately.
- The audit's provability bound makes dead-letter RETENTION load-bearing for auditability. Nothing prunes it today, so this is latent — but any future rotation or size cap silently converts provable rows into unprovable ones with no signal at either end. This is not a defect; it is a property that BECAME load-bearing and is recorded nowhere. Filed separately.
- `test-wake-detector.sh` D4 fails at this head AND identically at base, with an empty diff over detector files — pre-existing, tracked, not introduced here.
Authored by pepper (sb-it-1-dt); reviewed independently by mos-dt (sb-it-1-dt). The mos-dt-0 commit and fork identity does not identify the author — attribution collapse tracked separately.
Co-authored-by: mos-dt-0 <[email protected]>
Closes#944.
_has_hard_locator accepted only repo+issue / 40-hex sha / file — the forge vocabulary. The detector emits path (+snapshot_sha when attested) and NEVER emits file/issue/sha, so predicate and sole producer shared ZERO keys and every class=actionable board_file entry dead-lettered. Latent since #920, whose harness pinned the detector's own emission shape as its malformed example — the suite certified the gap it was written to guard.
Fix: `path` becomes a hard-locator arm, and ONLY path. Bare path-less snapshot_sha is a deliberate NON-arm (would widen past the board_file vocabulary); Q11(d) asserts it still quarantines at 7/40/64 chars, spanning the detector's ^[0-9a-f]{7,64}$ attestation range.
VERIFICATION
- Pipeline 2105 terminal-green at fa36da8. Its `test` step reaches all nine wake harnesses via turbo -> packages/mosaic `test` -> `test:framework-shell`, which names each suite explicitly. The two-levels-down indirection matters: no search of .woodpecker/* can see it, and that is exactly why this question was got wrong earlier today and then corrected. CI therefore DOES attest the quarantine suite and the detector suite at this head.
- Independent review (mos-dt, consumer on the affected lane) PASS at fa36da8, from a detached worktree: predicate provably unmoved from fb3c3c3 (comment-stripped sha256 identical, _has_hard_locator body byte-identical), RED control at base reproduced exactly 8 failures all Q11 including "got 6".
- Third reviewer (wake-judge) ACCEPT on both judgment calls: the Q1 assertion reversal is a legitimate correction (the flip was forced, not elective — base fixtures red 19 assertions against the head predicate) and path-alone satisfies §2.1, whose operative test is "one targeted call, never a search" — two of its four named exemplars already resolve to current state. Requiring path+snapshot_sha jointly would permanently dead-letter a declared source class and conflict with #940's advisory-fields ruling.
- Judge's mutation criterion met: with the reconciled exemption disabled, the gate-level assertion ("an ORIENTATION-tier enumeration must NOT be quarantined") dies at this head and did not exist as a casualty before F1.
- D4 (detector lock re-acquisition) fails intermittently at base AND head; git diff base..head over the detector files is EMPTY, so it is out of this PR's surface on structural grounds rather than on a re-roll. Known defect, fix identified (detector.sh:516, fd 9 leaked into sleep), tracked separately.
KNOWN RESIDUALS
- ENUM-B is now the sole address-free reconciled fixture, so the exemption's gate-level guard is a population of one. Safe by population, not by design. Author follow-up: assert ENUM-B carries no hard-locator arm so the harness guards its own premise.
- The binding spec (CONVERGED-DESIGN.md §2.1, separate repo) still enumerates four forge tokens and reads narrower than the shipped gate. Tracked as #948, sequenced after the dragon-lin reseed.
- Hard-locator arms are type-loose: repo/file/path accept any non-null JSON value. Pre-existing; `sha` fails closed only by accident of test(). Tracked separately.
Authored by pepper (sb-it-1-dt); reviewed independently by mos-dt (sb-it-1-dt) and wake-judge. The mos-dt-0 commit/fork identity does not identify the author — attribution collapse tracked in #3092.
Co-authored-by: mos-dt-0 <[email protected]>
grep is line-oriented, so a multi-line knob value passed the per-line anchors and was still fatal in arithmetic. Replaced with a case pattern matching the whole string, so an embedded or leading newline rejects. Manifest bumped 0.6.12 -> 0.6.13: three materially different detectors had shipped under one version string, and version= is the component sole self-identity claim.
Authored-by: pepper
Reviewed-by: mos-dt (independent, at this head; transfer proven by blob-hash equality)
Merged-by: Mos
Co-authored-by: mos-dt-0 <[email protected]>
The slack knob was interpolated raw into $((...)) under set -u: a malformed value was FATAL to the poll, falsifying the poll-never-fails invariant, and a negative value inverted the guard to deny-all. Shape validation alone was insufficient — bash reads a leading zero as octal, so 08/09 passed the regex yet were fatal and 0300 silently meant 192. Now validated ^[0-9]{1,9}$ with a loud fallback to 300, then forced to base-10 via 10# so the knob means what the operator wrote.
Authored-by: pepper
Reviewed-by: mos-dt (independent, found both the original defect and the radix residual)
Merged-by: Mos
Co-authored-by: mos-dt-0 <[email protected]>
Adapter emits snapshot sha/ts out-of-band on fd 3 so a changing value never enters the delta-gate hash. Detector validates advisorily (sha regex, epoch sanity before arithmetic, future-skew slack); malformed metadata is dropped loudly and never gates the wake. Digest renders snapshot_sha/snapshot_ts plus a git-show re-verify hint. Adapters that never write fd 3 are byte-identical.
Reviewed-by: Mos (design, independent)
Reviewed-by: mos-dt (artifact, hardening §2)
Co-authored-by: mos-dt-0 <[email protected]>
Part of #869
Mos (id-11) Gate-16 merge: independent APPROVE @b6f36564 (8/8, verified vs real production settings template), author id2 != approver id11, clean mosaic-coder author, CI green wp1988.
Co-authored-by: jason.woltje <[email protected]>
Co-committed-by: jason.woltje <[email protected]>
Part of #869
Mos (id-11) Gate-16 merge: independent APPROVE @75235ef8 (9/9, no live host mutation), author id2 != approver id11, CI green wp1971.
Co-authored-by: jason.woltje <[email protected]>
Co-committed-by: jason.woltje <[email protected]>
GLPI helpdesk workflow skills written against the portable
tools/glpi/ tooling (session-init.sh, ticket-list.sh, ticket-create.sh),
cross-linked via [[glpi-*]]:
- glpi-solve — close a ticket by setting status Solved (5); GLPI auto-closes
- glpi-followup — add a followup via the top-level /ITILFollowup endpoint
- glpi-sweep — read-only hunt for done-but-open tickets needing Solve
- glpi-list — query tickets by status/recency
- glpi-create — open a new ticket
Core rule encoded: completing work means setting status Solved, not just
posting a resolution followup (a followup documents; only Solved auto-closes).
Note: illustrative examples in the bodies are USC-flavored (M2M / helpdesk
ticket numbers) and can be genericized in review if preferred.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_019GjBgrb9tHgvq414Fqj37c
Fresh `mosaic gateway install` (npm) left the gateway DB schema empty —
sign-in 500'd with `relation "users" does not exist`, and every entry
point (auth, bootstrap setup) failed because they all query the users
table first. Five stacked bugs on the local (PGlite) tier:
1. `packages/db/package.json` `files: ["dist"]` excluded the `drizzle/`
SQL migrations from the published tarball.
2. `runMigrations()` only supports postgres-js — unusable for embedded
PGlite.
3. `apps/gateway/src/database/database.module.ts` never invoked
migrations at startup.
4. `createPgliteDb` didn't load pgvector, so migration 0001's
`CREATE EXTENSION vector` failed.
5. Drizzle's PG migrator wraps every migration in one outer
transaction, which trips Postgres' `check_safe_enum_use` on
migration 0009 (`ALTER TYPE ADD VALUE 'pending'` → `SET DEFAULT
'pending'` in the same tx).
Changes:
- Ship `drizzle/` in the published tarball.
- `createPgliteDb` loads `@electric-sql/pglite/vector`.
- New `runPgliteMigrations(handle)` walks the Drizzle journal and
runs each statement-breakpoint chunk through PGlite's `client.exec()`
(autocommit per statement). Records into `drizzle.__drizzle_migrations`
for interop with the postgres-js path. Per-statement try/catch
surfaces which statement of which migration failed.
- `DatabaseModule` runs migrations in `OnModuleInit` before
`app.listen()`. Local tier: explicit `runPgliteMigrations` then
`storageAdapter.migrate()`. Postgres tier: just `storageAdapter.migrate()`,
which already calls `runMigrations(url)` internally — no double-call.
- Removed `packages/storage/src/test-utils/pglite-with-vector.ts`. The
"intentionally not exported" rationale is moot now that migration
0001 forces pgvector load anyway. The integration test uses
`createPgliteDb` + `runPgliteMigrations` from `@mosaicstack/db`.
Tests: BetterAuth tables exist after migrate; idempotent (re-runs 0009);
partial-failure surfaces statement-level context and leaves no ledger row.
QA on a fresh PGlite install:
- `Applying PGlite schema migrations...` then `Initializing storage
adapter (pglite)...` in startup log.
- `GET /api/bootstrap/status` → `{"needsSetup":true}` HTTP 200 (was 500).
- `POST /api/bootstrap/setup` reaches Zod validator (was 500).
Scope: this PR fixes the local (PGlite) tier. Postgres-tier first
install still has the outer-transaction problem and a journal ordering
bug (0009's `when` < 0008's). Documented inline as TODO and in the
scratchpad — needs a separate change with real-Postgres validation.
Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
- CRIT-1: Validate cert subjectUserId against grant.subjectUserId from DB;
use authoritative DB value in FederationContext
- CRIT-2: Add @Inject(GrantsService) decorator (tsx/esbuild requirement)
- HIGH-1: Validate UTF8String TLV tag, length, and bounds in OID parser
- HIGH-2: Collapse all 403 wire messages to a generic string to prevent
grant enumeration; keep internal logger detail
- HIGH-3: Assert federation wire envelope shape in all guard tests
- HIGH-4: Regression test for subjectUserId cert/DB mismatch
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Adds FederationAuthGuard that validates inbound mTLS client certs on
federation API routes. Extracts custom OIDs (grantId, subjectUserId),
loads the grant+peer from DB in one query, asserts active status, and
validates cert serial as defense-in-depth. Attaches FederationContext
to requests on success and uses federation wire-format error envelopes
(not raw NestJS exceptions) for 401/403 responses.
New files:
- apps/gateway/src/federation/oid.util.ts — shared OID extraction (no dupe ASN.1 logic)
- apps/gateway/src/federation/server/federation-auth.guard.ts — guard impl
- apps/gateway/src/federation/server/federation-context.ts — FederationContext type + module augment
- apps/gateway/src/federation/server/index.ts — barrel export
- apps/gateway/src/federation/server/__tests__/federation-auth.guard.spec.ts — 11 unit tests
Modified:
- apps/gateway/src/federation/grants.service.ts — adds getGrantWithPeer() with join
- apps/gateway/src/federation/federation.module.ts — registers FederationAuthGuard as provider
Closes#462
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
- HIGH-A: resolveEntry now uses promise-cache pattern so concurrent
callers serialize on a single in-flight build, eliminating duplicate
key material in heap and duplicate DB round-trips
- HIGH-B: flushPeer destroys the evicted undici Agent so stale TLS
connections close on cert rotation
- MED-C: add regression test for PEER_MISCONFIGURED when
STEP_CA_ROOT_CERT_PATH is unset
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
CRIT-1: regenerate pnpm-lock.yaml so apps/gateway resolves [email protected].6
(prior PR pushed package.json without lockfile update; CI failed with
ERR_PNPM_OUTDATED_LOCKFILE). Incidentally cleans 57 lines of stale
peer-dep entries.
CRIT-2: cache-hit test no longer swallows resolveEntry errors. Calls the
private method directly twice and asserts identity equality plus a
single DB select, removing the silent-failure path the prior assertion
allowed.
HIGH-1: mTLS Agent now pins Step-CA root via STEP_CA_ROOT_CERT_PATH.
Without the env var resolveEntry throws PEER_MISCONFIGURED, refusing to
dial peers against the public trust store. PEM is read once and cached
on the service instance.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
Implements FederationClientService — a NestJS injectable that dials peer
gateways over mTLS (undici Agent with cert+sealed-key from federation_peers),
invokes list/get/capabilities verbs, validates responses via Zod, and surfaces
all failure modes as typed FederationClientError with a coherent error code
taxonomy (PEER_NOT_FOUND, PEER_INACTIVE, PEER_MISCONFIGURED, NETWORK,
FORBIDDEN, HTTP_{status}, INVALID_RESPONSE).
Per-peer Agent instances are cached in a Map for the service lifetime;
flushPeer(peerId) invalidates the cache for M5/M6 cert rotation and
revocation events.
Wired into FederationModule providers + exports so QuerySourceService
(M3-09) can inject it.
13 unit tests covering all required scenarios via undici MockAgent +
real sealClientKey/unsealClientKey round-trip.
Closes#462
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Picks up auth command and spec written by parallel agent, and updated
mosaic cli.ts wiring from parallel development during cli-unification.
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Adds mosaic forge run|status|resume|personas list subcommands to
@mosaicstack/forge, wires registerForgeCommand into the root mosaic CLI,
and ships a smoke test asserting command structure. Ref CU-05-01
cli-unification-20260404.
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
- Remove @mosaicstack/cli (absorbed into @mosaicstack/mosaic)
- Add all 21 remaining workspace packages so the multi-package
update checker actually covers every published package
@mosaic/mosaic is now the single package providing both:
- 'mosaic' binary (CLI: yolo, coord, prdy, tui, gateway, etc.)
- 'mosaic-wizard' binary (installation wizard)
Changes:
- Move packages/cli/src/* into packages/mosaic/src/
- Convert dynamic @mosaic/mosaic imports to static relative imports
- Add CLI deps (ink, react, socket.io-client, @mosaic/config) to mosaic
- Add jsx: react-jsx to mosaic's tsconfig
- Exclude packages/cli from workspace (pnpm-workspace.yaml)
- Update install.sh to install @mosaic/mosaic instead of @mosaic/cli
- Bump version to 0.0.17
This eliminates the circular dependency between @mosaic/cli and
@mosaic/mosaic that was blocking the build graph.
git pull --rebase fails with 'cannot pull with rebase: You have
unstaged changes' when the skills repo has local modifications.
Fix: detect dirty index/worktree, stash before pull, restore after.
Also gracefully handle pull failures (warn and continue with existing
checkout) and stash pop conflicts.
Two bugs causing 'EACCES: permission denied, copyfile' when source
and target are the same path (e.g. wizard with sourceDir == mosaicHome):
1. No same-path guard — syncDirectory tried to copy every file onto
itself; git pack files are read-only (0444) so copyFileSync fails.
2. excludeGit only matched top-level .git — nested .git dirs like
sources/agent-skills/.git were copied, hitting the same permission
issue.
Fixes:
- Early return when resolve(source) === resolve(target)
- Match .git dirs at any depth via dirName and relPath checks
- Skip files inside .git/ paths
Added file-ops.test.ts with 4 tests covering all cases.
- mosaic-init bash script: detect existing SOUL.md/USER.md/TOOLS.md and
prompt user to keep, import (re-use values as defaults), or overwrite.
Non-interactive mode exits cleanly unless --force is passed.
Overwrite creates timestamped backups before replacing files.
- launch.ts checkSoul(): prefer 'mosaic wizard' over legacy bash script
when SOUL.md is missing, with fallback to mosaic-init.
- detect-install.ts: pre-populate wizard state with existing values when
user chooses 'reconfigure', so they see current settings as defaults.
- soul-setup.ts: show existing agent name and communication style as
defaults during reconfiguration.
- Added tests for reconfigure pre-population and reset non-population.
The #351 merge landed before the force-push with full commands.
This adds the missing subcommands:
- mosaic coord {init,status,mission,continue,run,smoke,resume}
→ delegates to tools/orchestrator/*.sh with --claude/--codex/--pi/--yolo
- mosaic prdy {init,update,validate,status}
→ delegates to tools/prdy/*.sh with --claude/--codex/--pi
- mosaic seq {check,fix,start}
→ sequential-thinking MCP management (native TS)
- mosaic upgrade {release,check,project}
→ delegates to tools/_scripts/mosaic-release-upgrade and mosaic-upgrade
Also removes duplicate prdy registration (was in both launch.ts and
the old registerPrdyCommand — now only in launch.ts).
Templates moved from packages/mosaic/templates/ to
packages/mosaic/framework/templates/ in #345. The test's
existsSync guard silently skipped the copy, causing writeSoul
to early-return without writing SOUL.md.
The @mosaic scope registry is configured in ~/.npmrc. Passing --registry
on the install command overrides the default registry for ALL packages,
causing non-@mosaic deps like @clack/prompts to 404 against Gitea.
Completes the bootstrap repo migration with remaining files:
- PowerShell scripts (.ps1) for Windows support (bin/ + tools/)
- Runtime adapters (claude, codex, generic, pi)
- Guides (17 .md files) and profiles (domains, tech-stacks, workflows)
- Wizard test suite (6 test files from bootstrap tests/)
- Memory placeholder, audit history
Bootstrap repo (mosaic/bootstrap) is now fully superseded:
- All 335 files accounted for
- 5 build config files (package.json, tsconfig, etc.) not needed —
monorepo has its own at packages/mosaic/
- skills-local/ superseded by monorepo skills/ with mosaic-* naming
- src/ already lives at packages/mosaic/src/
Kaniko fails when COPY --from=builder references a path that doesn't
exist. The web app had no public/ directory, causing build-web to fail
with 'no such file or directory' on the public assets COPY step.
Publish pipeline:
- Add publish-npm step to .woodpecker/publish.yml — publishes all
@mosaic/* packages to Gitea npm registry on main push/tag
- Requires gitea_npm_token Woodpecker secret (package:write scope)
- publish-npm runs after build, parallel with Docker image builds
- pnpm publish resolves workspace:* to concrete versions automatically
Package configuration:
- All 20 packages versioned at 0.0.1-alpha.1
- publishConfig added to all packages (Gitea registry, public access)
- files field added to all packages (ship only dist/)
- @mosaic/forge includes pipeline/ assets in published package
Meta package (@mosaic/mosaic):
- Now depends on @mosaic/forge, @mosaic/macp, @mosaic/prdy,
@mosaic/quality-rails, @mosaic/types
- npm install @mosaic/mosaic pulls in the standalone framework
Build fixes:
- Fix forge and macp tsconfig rootDir: '.' -> 'src' so dist/index.js
resolves correctly (was dist/src/index.js)
- Exclude __tests__ and vitest.config from build includes
- Clean stale build artifacts from old rootDir config
Required Woodpecker secret:
woodpecker secret add mosaic/mosaic-stack \
--name gitea_npm_token --value '<token>' \
--event push,manual,tag
Skills:
- Rename all repo skills to mosaic-<name> convention (jarvis -> mosaic-jarvis, etc.)
- Update frontmatter name: fields to match directory names
- New mosaic-board skill: standalone Board of Directors multi-persona review
- New mosaic-forge skill: standalone Forge specialist pipeline
- New mosaic-prdy skill: PRD lifecycle (init/update/validate/status)
Wizard (packages/mosaic):
- Add mosaic-board, mosaic-forge, mosaic-prdy, mosaic-standards, mosaic-macp
to RECOMMENDED_SKILLS
- Add new skills to SKILL_CATEGORIES for categorized browsing
Framework scripts (~/.config/mosaic/bin):
- mosaic (launcher): load skills from both skills/ and skills-local/ for Pi
- mosaic-doctor: add --fix flag for auto-wiring skills into all harnesses,
Pi skill dir checks, Pi settings.json validation, mosaic-* presence checks
- mosaic-sync-skills: add Pi as 4th link target, fix find to follow symlinks
in skills-local/, harden is_mosaic_skill_name() with -L fallback
- mosaic-link-runtime-assets: add Pi settings.json skills path patching,
remove duplicate extension copy (launcher --extension is single source)
- mosaic-migrate-local-skills: add Pi to skill_roots, fix find for symlinks
YAML fixes:
- Quote description values containing colons in mosaic-deploy and
mosaic-woodpecker SKILL.md frontmatter (fixes Pi parse errors)
The insights table uses vector(1536) but no migration enables the pgvector
extension. CI postgres (pgvector/pgvector:pg17) has the extension available
but it must be explicitly created before use.
Adds CREATE EXTENSION IF NOT EXISTS vector at the top of
0001_cynical_ultimatum.sql (the first migration referencing vector type).
The migration file 0001_cynical_ultimatum.sql existed on disk but was not
registered in the Drizzle journal (_journal.json). This caused fresh-database
migrations (CI) to skip creating tables (agent_logs, insights, preferences,
skills, summarization_jobs), then 0002_nebulous_mimic.sql would fail trying
to ALTER the non-existent preferences table.
Fix: insert cynical_ultimatum at idx 1 in the journal and shift all
subsequent entries (idx 2-7).
Verified: pnpm test passes (347 tests, 35 tasks).
BullMQ v5 RedisConnection constructor does:
Object.assign({ port: 6379, host: '127.0.0.1' }, opts)
When opts is a URL string (via 'as unknown as ConnectionOptions'),
Object.assign only copies character-index properties from the string,
so the default port 6379 was never overridden — causing ECONNREFUSED
against the wrong port instead of the configured 6380.
Fix: parse VALKEY_URL with new URL() and return a plain RedisOptions
object { host, port, ... } so Object.assign merges it correctly.
- plugins/macp/src/index.ts: use createRequire + dynamic import() for OC SDK
- plugins/macp/src/acp-runtime-types.ts: local ACP runtime type definitions
- plugins/macp/src/macp-runtime.ts: DEFAULT_REPO_ROOT and PI_RUNNER_PATH use
os.homedir() instead of hardcoded /home/user/
- plugins/mosaic-framework/src/index.ts: removed hardcoded SDK import
- No hardcoded /home/ paths remain in any plugin source file
- Plugin works on any machine with openclaw installed globally
Adds 'agent' column to specify which model should execute each task.
Values: codex | sonnet | haiku | glm-5 | opus | — (auto)
Pipeline crons use this to spawn the cheapest capable model per task.
Phase 8 tasks assigned: P8-001/002/003=codex, P8-004=haiku
- DB client: configure connection pool (max=20, idle_timeout=30s, connect_timeout=5s)
- DB schema: add missing indexes for auth sessions, accounts, conversations, agent_logs
- DB schema: promote preferences(user_id,key) to UNIQUE index for ON CONFLICT upsert
- Drizzle migration: 0003_p8003_perf_indexes.sql
- preferences.service: replace 2-query SELECT+INSERT/UPDATE with single-round-trip upsert
- conversations repo: add ORDER BY + LIMIT to findAll (200) and findMessages (500)
- session-gc.service: make onModuleInit fire-and-forget (removes cold-start TTFB block)
- next.config.ts: enable compress, productionBrowserSourceMaps:false, image avif/webp
- docs/PERFORMANCE.md: full profiling report and change impact notes
- WorkspaceService: path resolution, git init/clone, directory lifecycle (create/delete/exists), user and team root provisioning
- ProjectBootstrapService: orchestrates DB record creation (via Brain) + workspace directory init in a single call
- TeamsService: isMember, canAccessProject, findAll, findById, listMembers via Drizzle DB queries
- WorkspaceController: POST /api/workspaces — auth-guarded project bootstrap endpoint
- TeamsController: GET /api/teams, /:teamId, /:teamId/members, /:teamId/members/:userId
- WorkspaceModule wired into AppModule
- workspace.service.spec.ts: 5 unit tests for resolvePath (user, team, fallback, env var, default)
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Implements three-tier garbage collection for agent sessions:
- SessionGCService.collect() for immediate per-session cleanup on destroySession()
- SessionGCService.sweepOrphans() for daily cron sweep of orphaned Valkey keys
- SessionGCService.fullCollect() for cold-start aggressive cleanup via OnModuleInit
- /gc slash command wired into CommandExecutorService + registered in CommandRegistryService
- SESSION_GC_CRON (daily 4am) added to CronService
- GCModule provides Valkey (ioredis via @mosaic/queue) and is imported by AgentModule, LogModule, CommandsModule, AppModule
- 8 Vitest unit tests covering all three GC tiers
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Each step was re-running pnpm install independently, and all quality
steps (typecheck, lint, format, test) ran in parallel. On merge commits
with more accumulated code this pushed the CI runner over its memory
limit (exit code 254 = OOM kill).
Fix:
- install once, share node_modules via Woodpecker workspace volume
- sequential execution: install → typecheck → lint → format → test → build
- corepack enable in each step (fresh container) but no redundant install
- Add @Inject() to all gateway constructor params (required without emitDecoratorMetadata)
- AgentService: ProviderService, CoordService
- RoutingService: ProviderService
- ProvidersController: ProviderService, RoutingService
- SessionsController: AgentService
- Fix coord controller ALLOWED_ROOTS to walk up to monorepo root (pnpm-workspace.yaml)
- Gateway now boots and serves all routes correctly
Co-Authored-By: Claude Opus 4.6 <[email protected]>
Pi SDK is ESM-only. tsx (esbuild) doesn't emit decorator metadata,
so NestJS constructor injection fails without explicit @Inject().
- Set "type": "module" in gateway package.json
- Switch tsconfig to NodeNext module resolution
- Add @Inject(AgentService) to ChatController and ChatGateway
Tested end-to-end: REST /api/chat → Pi SDK → Anthropic → response OK.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
- #62: piSession.dispose() missing in destroySession
- #63: React anti-pattern in TUI agent:end handler
Co-Authored-By: Claude Opus 4.6 <[email protected]>
Jason directed: build Pi TUI → Gateway → Discord communication
spine before backfilling horizontal layers.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
Break PRD into 8 milestones (Phase 0–7) with 59 issues on Gitea.
Populate TASKS.md, update mission manifest, initialize scratchpad.
Repo created at git.mosaicstack.dev/mosaic/mosaic-stack.
Co-Authored-By: Claude Opus 4.6 <[email protected]>
2026-03-12 19:51:51 -05:00
3508 changed files with 346072 additions and 345833 deletions
- This file is authoritative for repo-local operations.
-`CLAUDE.md` is a compatibility pointer to `AGENTS.md`.
- Follow universal rails from `~/.config/mosaic/guides/` and `~/.config/mosaic/rails/`.
Mosaic Stack is a self-hosted, multi-user AI agent platform. TypeScript monorepo with NestJS gateway, Next.js web dashboard, Pi SDK agent runtime, and plugin architecture for Discord/Telegram.
- ESM everywhere (`"type": "module"`, `.js` extensions in imports)
- NodeNext module resolution in all tsconfigs
- Scratchpads are mandatory for non-trivial tasks
## docs/TASKS.md — Schema (CANONICAL)
The `agent` column specifies the required model for each task. **This is set at task creation by the orchestrator and must not be changed by workers.**
**This project is ALPHA. All versions MUST be `0.0.x`.**
- The `0.1.0` release is FORBIDDEN until Jason explicitly authorizes it.
- Every milestone bump increments the patch: `0.0.20` → `0.0.21` → `0.0.22`, etc.
- ALL package.json files in the monorepo MUST stay in sync at the same version.
- Use `scripts/version-bump.sh <version>` to bump — it enforces the alpha constraint and updates all packages atomically.
- The script rejects any version >= `0.1.0`.
- When creating a release tag, the tag MUST match the package version: `v0.0.x`.
**Milestone-to-version mapping** is defined in the PRD (`docs/PRD.md`) under "Delivery/Milestone Intent". Agents MUST use the version from that table when tagging a milestone release.
**Violation of this protocol is a blocking error.** If an agent attempts to set a version >= `0.1.0`, stop and escalate.
## Standards and Quality
- Enforce strict typing and no unsafe shortcuts.
- Keep lint/typecheck/tests green before completion.
- Prefer small, focused commits and clear change descriptions.
- **Config validation pattern**: Config files use exported validation functions + typed getter functions (not class-validator). See `auth.config.ts`, `federation.config.ts`, `speech/speech.config.ts`. Pattern: export `isXEnabled()`, `validateXConfig()`, and `getXConfig()` functions.
- **Config registerAs**: `speech.config.ts` also exports a `registerAs("speech", ...)` factory for NestJS ConfigModule namespaced injection. Use `ConfigModule.forFeature(speechConfig)` in module imports and access via `this.config.get<string>('speech.stt.baseUrl')`.
- **Conditional config validation**: When a service has an enabled flag (e.g., `STT_ENABLED`), URL/connection vars are only required when enabled. Validation throws with a helpful message suggesting how to disable.
- **Boolean env parsing**: Use `value === "true" || value === "1"` pattern. No default-true -- all services default to disabled when env var is unset.
## Gotchas
- **Prisma client must be generated** before `tsc --noEmit` will pass. Run `pnpm prisma:generate` first. Pre-existing type errors from Prisma are expected in worktrees without generated client.
- **Pre-commit hooks**: lint-staged runs on staged files. If other packages' files are staged, their lint must pass too. Only stage files you intend to commit.
- **vitest runs all test files**: Even when targeting a specific test file, vitest loads all spec files. Many will fail if Prisma client isn't generated -- this is expected. Check only your target file's pass/fail status.
* DTO for querying activity logs with filters and pagination
*/
exportclassQueryActivityLogDto{
@IsOptional()
@IsUUID("4",{message:"workspaceId must be a valid UUID"})
workspaceId?: string;
@IsOptional()
@IsUUID("4",{message:"userId must be a valid UUID"})
userId?: string;
@IsOptional()
@IsEnum(ActivityAction,{message:"action must be a valid ActivityAction"})
action?: ActivityAction;
@IsOptional()
@IsEnum(EntityType,{message:"entityType must be a valid EntityType"})
entityType?: EntityType;
@IsOptional()
@IsUUID("4",{message:"entityId must be a valid UUID"})
entityId?: string;
@IsOptional()
@IsDateString({},{message:"startDate must be a valid ISO 8601 date string"})
startDate?: Date;
@IsOptional()
@IsDateString({},{message:"endDate must be a valid ISO 8601 date string"})
endDate?: Date;
@IsOptional()
@Type(()=>Number)
@IsInt({message:"page must be an integer"})
@Min(1,{message:"page must be at least 1"})
page?: number;
@IsOptional()
@Type(()=>Number)
@IsInt({message:"limit must be an integer"})
@Min(1,{message:"limit must be at least 1"})
@Max(100,{message:"limit must not exceed 100"})
limit?: number;
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Hermes Agent
jason.woltjeandMos
jarvisandClaude Sonnet 4.6