Tags: who/ortus
Tags
Final commit that still ships the Copier-vendored bash toolkit. The next commit removes template/, copier.yaml, Makefile parity, scripts/check-ortus-parity.sh, and the archived copier tests. Python CLI under src/ortus/ is the only supported Ortus. See docs/sunset-notes.md.
feat(init): refine allowedDomains by --package-manager registry (ortu… …s-oxp9) Follow-up to the per-ecosystem allowedDomains fix. The bundled .claude/settings.json template keyed registries only on project_type (the language axis). Now the selected --package-manager also contributes its registry: yarn -> registry.yarnpkg.com (classic mirror) plus the npm registry; bun/npm/pnpm -> registry.npmjs.org. The npm registry is contributed by both the typescript project_type and these managers, so the rendered list is piped through `unique` to dedupe. The copier-era template/ copy is left untouched (it keys on the distinct copier-context language_profile variable, not package_manager). Add a parametrized render test in tests/test_init_render.py covering npm/pnpm/yarn/bun, asserting the manager registries appear and the list has no duplicate entries. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fix(tests): force NO_COLOR+TERM=dumb for init --help substring assert… …s (ortus-lj56) CI was failing test_help_advertises_new_flags because Rich emits SGR escape sequences inside option-table flag names (e.g. `--package-\x1b[33mmanager\x1b[0m`), breaking the literal `"--package-manager" in stdout` checks. Passing NO_COLOR=1+TERM=dumb to CliRunner.invoke makes Rich skip styling entirely so the substrings appear intact. Audit: no other tests in tests/ assert against --help output substrings that get split by Rich (the test_cli_verbs.py checks for short verb names and the intact "ortus <verb>" Usage line remain stable under FORCE_COLOR=1).
fix(ortus-bw8h): grind startup orphan sweep recovers cross-restart cl… …aims Per-iteration orphan detection (compute_delta = after.in_progress_ids - before.in_progress_ids) can never surface issues left in_progress by a prior grind that was killed mid-claim: they sit in before.in_progress_ids of the first iteration and get subtracted out of every later delta. Two changes: 1. Startup orphan sweep (Option 1): after acquiring the exclusive flock and snapshotting bd, every in_progress issue is by definition a cross-restart orphan (nothing else holds the flock). Apply the configured --orphan-policy to them and re-snapshot before the queue_drained check. 2. Default --orphan-policy flips warn → revert (Option 3 ride-along): the most common grind invocation now auto-recovers from a killed prior session instead of silent-spinning forever. Explicit warn is still available for operators who want manual investigation. Tests added for cross-restart sweep under warn / revert / escalate / default policies; existing warn-default tests now pin --orphan-policy warn explicitly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>