11 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Jason Woltje	b590a5c3d8	fix(git): accept http/https as one scheme class in comment URL verification (#991) ... 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.	2026-08-11 19:00:31 -05:00
Jason Woltje	2fa6bcd576	fix(git): #1007 — test-issue-comment-readback is a FIFTH affected suite (second census correction) ... 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	2026-07-31 07:27:10 -05:00
Jason Woltje	1afe2b36dc	fix(git): #1007 suite hermeticity — pin repo-local mosaic.gitIdentity in four test suites ... 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	2026-07-31 07:13:13 -05:00
Jason WoltjeandClaude Opus 4.8	7bc2dfb6c8	skills: add glpi-* family (solve, followup, sweep, list, create) ... 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	2026-07-20 18:04:53 -05:00
Jason Woltje	f05b198882	fix: remove stale bootstrap repo references from CLI error messages ... Replace 'cd ~/src/mosaic-bootstrap && bash install.sh' with 'npm install -g @mosaic/mosaic' now that bootstrap is archived.	2026-04-01 21:26:53 -05:00
Jason Woltje	6e6ee37da0	feat: complete framework migration — PowerShell, adapters, guides, profiles, tests ... 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/	2026-04-01 21:23:26 -05:00
Jason Woltje	b38cfac760	feat: integrate framework files into monorepo under packages/mosaic/framework/ ... Moves all Mosaic framework runtime files from the separate bootstrap repo into the monorepo as canonical source. The @mosaic/mosaic npm package now ships the complete framework — bin scripts, runtime configs, tools, and templates — enabling standalone installation via npm install. Structure: packages/mosaic/framework/ ├── bin/ 28 CLI scripts (mosaic, mosaic-doctor, mosaic-sync-skills, etc.) ├── runtime/ Runtime adapters (claude, codex, opencode, pi, mcp) ├── tools/ Shell tooling (git, prdy, orchestrator, quality, etc.) ├── templates/ Agent and repo templates ├── defaults/ Default identity files (AGENTS.md, STANDARDS.md, SOUL.md, etc.) ├── install.sh Legacy bash installer └── remote-install.sh One-liner remote installer Key files with Pi support and recent fixes: - bin/mosaic: launch_pi() with skills-local loop - bin/mosaic-doctor: --fix auto-wiring for all 4 harnesses - bin/mosaic-sync-skills: Pi as 4th link target, symlink-aware find - bin/mosaic-link-runtime-assets: Pi settings.json patching - bin/mosaic-migrate-local-skills: Pi skill roots, symlink find - runtime/pi/RUNTIME.md + mosaic-extension.ts Package ships 251 framework files in the npm tarball (278KB compressed).	2026-04-01 21:19:21 -05:00
Jason Woltje	e599f5fe38	fix(web): add public/ directory — fixes Docker build COPY failure ... 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.	2026-04-01 13:09:03 -05:00
Jason Woltje	92998e6e65	fix(ci): use gitea_token secret for npm publish	2026-04-01 12:51:06 -05:00
Jason Woltje	13934d4879	feat: npm publish pipeline + package versioning (0.0.1-alpha.1) ... 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	2026-04-01 12:46:13 -05:00
Jason Woltje	2ee7206c3a	feat: mosaic-* skill naming, new board/forge/prdy skills, doctor --fix auto-wiring ... 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)	2026-04-01 12:28:36 -05:00