fix(cli): harden meta init scaffold and close the Java CI reactor gate#82
Merged
Conversation
#37 — Java CI ran `mvn install -DskipTests` (compile-only), so the maven-plugin mojo tests never ran and a red reactor sat on main while PRs showed green. The conformance `java-smoke-compile` job → `java-reactor` now runs `mvn clean install` (full reactor WITH tests, all 14 modules). integration-tests (Docker) + fatjar-smoke (on-demand) stay out, documented. NOTE: branch protection must add the required check `conformance / java-reactor` (job renamed). #75 — meta init's scaffolded .metaobjects/.gitignore ignored only .gen-state/, so a per-target outDir under .metaobjects/<target>/src/generated/ (regenerable) got committed by default. Added `*/src/generated/` + re-include guards (!migrations/, !config.json, !package.meta.json) so the shadow is ignored but tracked artifacts can't be swept up. #77 — meta init scaffolds skills relative to cwd; in a monorepo subdir they don't load from a root-launched session (Claude Code discovers skills from cwd+ancestors, not down into subdirs). Added a monorepo-subdir warning (findGitRoot) pointing to `cd <repo-root> && meta init --docs-only --server <lang>`, and surfaced result.warnings on the init output path (previously dropped). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LuZWKnWzYGVnESijL7uuky
…e + monorepo-subdir fixes
This was referenced Jun 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Intent
Fix three contained GitHub bug issues (#37, #75, #77), all low-risk.
#37 (CI gate): Java CI ran 'mvn install -DskipTests' (compile-only) so the metaobjects-maven-plugin mojo tests never ran in CI — a red full-reactor 'mvn clean install' (the FR-032 ERR_RELATIVE_REF_IN_CANONICAL fixture break, since fixed in a9a962d) sat on main while every PR showed green. The conformance workflow's java-smoke-compile job is renamed java-reactor and now runs 'mvn clean install' (full 14-module reactor WITH tests, ~370 test files). integration-tests (separate workflow, needs Docker) and fatjar-smoke (on-demand) stay out by design, documented in the job comment. This PR's own CI runs the new gate — that IS the test. IMPORTANT human follow-up: branch protection's required-status-checks must add 'conformance / java-reactor' (job renamed) — I can't change branch protection from code.
#75 (codegen hygiene): meta init's scaffolded .metaobjects/.gitignore ignored only .gen-state/, so when a user points a per-target codegen outDir under .metaobjects//src/generated/ the regenerable generated shadow (canonical output lives at the configured outDir) escaped the ignore and got committed by default. Hardened METAOBJECTS_GITIGNORE_BODY with '*/src/generated/' plus '!migrations/'/'!config.json'/'!package.meta.json' re-include guards so the tracked artifacts can never be swept up. codegen-ts emits no framework shadow itself — confirmed — so the gitignore fix is the right layer.
#77 (agent-context UX): meta init scaffolds .claude/skills/metaobjects-* relative to cwd; in a monorepo subdir those skills don't load from a repo-root-launched Claude session (skills are discovered from cwd+ancestors, not down into subdirs). Added findGitRoot()+warnIfMonorepoSubdir() that warns when the init dir is a git subdir, pointing to 'cd && meta init --docs-only --server '; chose the low-risk WARN over auto-relocating skills. Also surfaced result.warnings on the normal init output path (previously dropped, so the warning would've been invisible).
All three are independent. cli bun test green except the pre-existing detectPackageManager/pm-detect env failure (lib/pm-detect.ts, untouched). No production Java code changed (#37 is CI config only).
What Changed
meta initscaffolded.metaobjects/.gitignore(METAOBJECTS_GITIGNORE_BODY) to also ignore*/src/generated/, so a regenerable per-target codegen shadow under.metaobjects/<target>/src/generated/no longer escapes the ignore and gets committed, with!migrations//!config.json/!package.meta.jsonre-include guards protecting the tracked artifacts (meta gen writes a regenerable per-target shadow copy under .metaobjects/<target>/ that meta init's .gitignore doesn't exclude (committed by default) #75).findGitRoot()+warnIfMonorepoSubdir()someta initwarns when run from a git subdirectory (where scaffolded.claude/skills/metaobjects-*won't load from a repo-root-launched session), pointing the user atcd <repo-root> && meta init --docs-only, and surfacedresult.warningson the normal init output path (previously silently dropped); covered by newinit.test.tscases (meta init scaffolds skills into cwd; in a monorepo subdir they aren't discovered from the repo root #77).java-smoke-compilejob tojava-reactorand switched it from compile-onlymvn install -DskipTeststo a full 14-modulemvn clean installwith tests, so the maven-plugin mojo tests actually run in CI (Add maven-plugin module to the CI gate — red Java reactor slipped past green PR checks #37).Risk Assessment
✅ Low: Three independent, well-bounded changes (CI config rename, defensive gitignore additions, an advisory-only init warning with tests) with no production-code logic risk and no internal job-dependency breakage; the only follow-up is the human-side branch-protection check rename the author already flagged.
Testing
Ran the cli init unit suite (25/25, including the new #75/#77 tests) and the full cli suite (346 pass; the lone failure is the pre-existing, unrelated pm-detect env test in untouched code). Then demonstrated each fix end-to-end with product-level artifacts: for #37 I executed the exact new gate command
mvn clean installon the full 14-module Java reactor (BUILD SUCCESS, every module green, and the previously-skipped maven-plugin mojo tests now run); for #75 I ran realmeta initand used realgit check-ignoreto prove the per-target generated shadow is ignored while migrations/config.json/package.meta.json stay tracked; for #77 I ranmeta initfrom a monorepo subdir (warning shown) and from the repo root (no warning). These are CLI/build surfaces with no UI, so evidence is CLI transcripts and the reactor build log rather than screenshots. Working tree left clean and build outputs removed.Evidence: #37 — full-reactor gate green + mojo tests now run
[INFO] BUILD SUCCESS — Reactor Summary: 14/14 modules SUCCESS Running com.metaobjects.mojo.MetaDataGeneratorMojoTest Running com.metaobjects.mojo.DocsMojoTest Running com.metaobjects.mojo.MetaDataVerifyMojoTest maven-plugin Tests run: 16, Failures: 0, Errors: 0, Skipped: 0 (+ per-suite counts, all green)Evidence: #37 — full mvn clean install reactor log
Evidence: #75 — scaffolded .gitignore + real git check-ignore
IGNORED -> .metaobjects/database/src/generated/Program.ts TRACKED -> .metaobjects/migrations/0001_init.sql TRACKED -> .metaobjects/config.json TRACKED -> .metaobjects/package.meta.jsonEvidence: #77 — meta init from monorepo subdir (warning shown)
meta: agent-context skills scaffolded into a monorepo subdir won't be discovered from a root-launched session (Claude Code only walks cwd + ancestors). Scaffold the context at the repo root instead: cd <repo-root> && meta init --docs-only --server typescriptEvidence: #77 — meta init at git repo root (no warning)
Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
server/typescript/packages/cli/src/commands/init.ts:42- The!migrations/,!config.json,!package.meta.jsonre-include guards in METAOBJECTS_GITIGNORE_BODY are currently no-ops: no positive pattern in the file matches those paths, so the negations protect nothing today. They're also placed before any hypothetical future broad pattern — and gitignore is last-match-wins, so a broad pattern appended after them would still win and override the re-includes. They function as documentation/intent rather than an actual safeguard, which is fine, but the comment's claim that they keep artifacts tracked 'even if a future broad pattern were added' is only true if that pattern is added above the guards.server/typescript/packages/cli/src/commands/init.ts:143- warnIfMonorepoSubdir fires whenever init runs in any git subdir with skills enabled, regardless of where the user will actually launch Claude. A user who intentionally keeps the project in a subdir and launches sessions from that same subdir will get skills discovered correctly but still sees the advisory warning telling them to re-init at the repo root. It's a benign, deliberate WARN (author chose this over auto-relocating), but it can be a mild false positive for the subdir-launched workflow.server/typescript/packages/cli/src/commands/init.ts:426- Addingfor (const w of result.warnings) log.warn(w)to the normal init path now surfaces ALL previously-dropped warnings (hand-edited-file refresh, orphaned context files, wired-root-import, invalid-config-replaced), not just the meta init scaffolds skills into cwd; in a monorepo subdir they aren't discovered from the repo root #77 monorepo warning. This is a net improvement (those were silently dropped), just noting the behavior change is broader than the meta init scaffolds skills into cwd; in a monorepo subdir they aren't discovered from the repo root #77 fix the comment describes — e.g. the wireRootMemory 'wired ... so the context loads' info message now prints as a warn.✅ **Test** - passed
✅ No issues found.
cd server/typescript/packages/cli && bun test test/init.test.ts— 25/25 pass incl. new #75/#77 casesbun test(full cli suite) — 346 pass, 1 fail (pre-existing, unrelateddetectPackageManagerenv failure in untouched lib/pm-detect.ts)#37:cd server/java && mvn clean install(exact new gate command, tests on) — BUILD SUCCESS, all 14 reactor modules green, maven-plugin mojo tests executed#75: ran realmeta initthengit check-ignoreon a simulated per-target shadow + tracked artifacts#77: ran realmeta initfrom a git subdir (warns) and from the git root (no warn)Checked remote CI viagh run list/view— confirmed target commit's CI not yet run✅ **Document** - passed
✅ No issues found.
✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.
Closes #37
Closes #75
Closes #77