Pilot the base quality preset on i18n-at and document adoption gaps

[jabelic]

Goal

Validate that the current project-standards MVP can produce a safe, reviewable adoption plan for one real public repository without forcing dependency-automation or stack-specific migrations.

Background

• project-standards currently ships an MVP centered on file planning, diffing, and safe apply flows.
• The repository README already suggests a slice-oriented workflow such as apply ... --include quality --dry-run, which makes a narrow first pilot possible.
• Jabelic-Works/i18n-at is a public TypeScript pnpm monorepo on main, making it a strong candidate for a first real-world validation.
• i18n-at already has dependency automation and an open dependency-maintenance issue (Jabelic-Works/i18n-at#78), so the first pilot should avoid turning into a Renovate-vs-Dependabot migration.

Scope

• Run diff and dry-run apply from project-standards against Jabelic-Works/i18n-at.
• Prefer the smallest non-dependency slice available, such as quality, if supported by the current preset layout.
• Review the proposed additions for managed docs, editor files, and quality-related config files.
• Record which changes are clearly safe, which require manual follow-up, and which reveal product gaps in project-standards.

Out of Scope

• Rolling out the full base preset to i18n-at in one PR.
• Replacing Dependabot with Renovate in this issue.
• Automatically mutating target-repo dependencies or scripts unless that behavior is already explicitly supported and remains small.
• Solving every stack-specific integration gap for all repository types.

Acceptance Criteria

• A reproducible pilot target and command path are documented.
• The diff and/or --dry-run result for i18n-at is reviewed and summarized.
• Any unsafe or unclear output is converted into clearly named follow-up issues instead of being absorbed into this issue.
• The pilot concludes whether the current MVP is ready for one small adoption PR or needs one small blocker issue first.

PR Plan

• 1 issue = 1 PR.
• Keep the PR focused on the pilot workflow, its findings, and only the minimal project-standards changes needed to make that pilot safe and reviewable.
• If the pilot exposes a larger product gap, open a follow-up issue rather than expanding this PR.

Proposed Plan

1. Confirm the smallest usable preset slice for a first pilot, ideally one that avoids dependency automation.
2. Run diff and dry-run apply against Jabelic-Works/i18n-at.
3. Classify the output into safe additions, expected manual follow-up, and blockers.
4. Make only the minimal project-standards adjustments required to support a clean pilot.
5. Document the pilot result and the next recommended issue.

Notes

• Suggested label: enhancement.
• If the preset cannot be scoped away from dependency automation, split that blocker into a separate issue before attempting adoption.

[jabelic]

Validation run completed against the local checkout of Jabelic-Works/i18n-at.

What I ran

• node packages/cli/dist/index.js diff /Users/s21612/Home/dev/Jabelic-Works/i18n-at --include quality --json
• node packages/cli/dist/index.js apply /Users/s21612/Home/dev/Jabelic-Works/i18n-at --include quality --dry-run --json
• node packages/cli/dist/index.js apply /Users/s21612/Home/dev/Jabelic-Works/i18n-at --include eslint,oxlint,oxformat --dry-run --json

Result

• Validation only. No apply step was performed.
• git status --short remained clean in both project-standards and i18n-at after the run.
• The current quality include path proposed 5 creates:
  • .cursor/commands/quality-check.md
  • .oxfmtrc.json
  • .oxlintrc.json
  • eslint.config.mjs
  • renovate.json
• A narrower non-Renovate run with --include eslint,oxlint,oxformat proposed 3 creates:
  • .oxfmtrc.json
  • .oxlintrc.json
  • eslint.config.mjs

Findings

• quality is currently too broad for a dependency-free pilot because it also pulls in renovate.json and a Cursor-only command file.
• The planned eslint.config.mjs imports @jabelic/eslint-config/base, but i18n-at does not currently depend on @jabelic/eslint-config.
• i18n-at already has .github/dependabot.yml, so proposing renovate.json in the first pilot introduces policy noise before the baseline quality path is validated.
• i18n-at also has a package-level ESLint config at packages/examples/nextjs-app/eslint.config.mjs, so root-level adoption should stay explicit and reviewable.

Follow-up issues

• Decouple dependency automation and Cursor files from the quality include slice #3 Decouple dependency automation and Cursor files from the quality include slice
• Surface missing shared ESLint config prerequisites during planning #4 Surface missing shared ESLint config prerequisites during planning

Recommendation

Do not apply anything to i18n-at yet. Resolve #3 and #4 first, then re-run the same validation commands to confirm the pilot path is small, explicit, and dependency-safe.