canon: separate Starlight worldview from Arcanea fiction

[frankxai]

Decision

Separates Starlight from Arcanean cosmology and from real-world religious ultimates without deleting legacy material.

Changes

• replaces the GOD — THE SOURCE — THE TAO equivalence in arcanea-lore/CANON.md with an unnamed, unknowable fictional Source
• states that Lumina is not Starlight, Shinkami is not a real-world ultimate, and the Field/frequencies are fictional mechanics
• adds visible quarantine/fiction labels to three high-risk legacy library texts
• removes the unsupported Celtic quantum-history claim from the public library page
• adds a preserved migration/conflict ledger
• adds ratcheting ontology lint, unit fixtures, and PR workflow

Preserved unresolved conflicts

1. arcanea-lore/CANON.md, .arcanea/lore/CANON_LOCKED.md, and .claude/lore/ARCANEA_CANON.md each claim or receive canonical authority. This PR does not silently demote any of them.
2. Starlight Intelligence remains staged in .arcanea/lore/CANON_LOCKED.md as a mythic force; this conflicts with Starlight as a mass noun and transmission ontology.
3. Gate frequencies remain valid only as fictional mechanics; a full corpus sweep is still required.
4. Quarantined quantum-consciousness and universalizing texts require substantive rewrites or retirement from documentary surfaces.

Verification

• local unit tests: node --test .claude/ci/ontology-boundary-lint.test.mjs — 2/2 passing
• connector comparison: 9 files changed, branch 9 commits ahead and 0 behind main

Merge posture

Draft by design. Do not merge until the canon-authority conflict and the Arcanean Starlight Intelligence name collision are resolved.

[claude]

Review — PR #122

This PR is explicitly marked draft/not-ready-to-merge by the author, so I've focused on the mechanics of the new tooling (the ontology linter + CI workflow) rather than re-litigating the lore/governance decisions, which the PR body already flags as unresolved.

Code quality & best practices

• execFileSync('git', [...]) is used with an argument array rather than a shell string in both addedContent() and the --all branch of main() (.claude/ci/ontology-boundary-lint.mjs:32,50) — good, avoids shell injection entirely.
• The bounded quantifiers in the regexes (.{0,90}, .{0,40}) are a nice touch to keep this ReDoS-safe.
• (?<!not\s) on the starlight-deity / lumina-starlight / shinkami-god rules (lines 9–11) is vestigial: each pattern requires exact adjacency (is God, is Starlight, …), so a real negation like "Starlight is not God" already fails to match without the lookbehind (the word after is isn't one of the listed alternatives). The lookbehind only guards against the ungrammatical "not Starlight is God". Harmless, but it implies a negation-safety property the code doesn't actually provide via that mechanism — worth a comment or removal so a future contributor doesn't rely on it when adding similar rules.

Potential bugs

1. starlights-species rule is a likely false-positive generator (.claude/ci/ontology-boundary-lint.mjs:17): /\bthe Starlights\b.{0,40}\b(?:species|race|beings|were|are)\b/i. Unlike the other "X is Y" rules, this one has no negation guard, and are/were are bare words in the alternation. A legitimate, canon-correct sentence like "The Starlights are not a species, they're a metaphor for benevolent transmission" still matches, because .{0,40} happily consumes the single space before are and the alternation only needs are itself, not are a species. This is exactly the kind of corrective sentence this PR is trying to normalize elsewhere (e.g. the STARLIGHT_ONTOLOGY_MIGRATION.md boundary language), so it'll likely trip on the next legitimate edit to a non-allowlisted file.
2. --all mode will crash on binary files (.claude/ci/ontology-boundary-lint.mjs:49-50): unlike addedContent(), which filters to .md/.mdx/.ts/.tsx/.js/.mjs/.json/.yaml/.yml (line 43), the --all branch calls readFileSync(path, 'utf8') on every path returned by git ls-files with no extension filter. Any tracked binary (images, fonts, etc., of which this Next.js repo has several) will throw and abort the whole scan instead of being skipped. It's not wired into the new CI workflow today, so it won't bite in this PR, but it ships as broken functionality a future contributor will hit the first time they run it locally as implied by the flag name.

Test coverage

• .claude/ci/ontology-boundary-lint.test.mjs covers 10 of the 11 RULES entries — starlights-species (the rule flagged above) has zero test coverage, positive or negative. A negative test case with a natural negation sentence would have caught the false-positive issue before merge.
• Only scan() is unit-tested; addedContent()'s diff-parsing (which path a changed line gets attributed to) and the --all code path in main() have no coverage at all.

Performance / CI design

• .github/workflows/ontology-boundary.yml triggers on **/*.md, *.mdx, *.ts, *.tsx, *.js, *.mjs, *.json, *.yaml, *.yml — essentially the entire codebase, not just lore/content paths. The repo already has a purpose-built, similarly-scoped lore-canon.yml (per .claude/CLAUDE.md) restricted to lore paths; this new workflow will instead run as a check on nearly every PR touching any source, config, or doc file, including ones with no relation to lore/ontology. Consider scoping paths: to content/**, arcanea-lore/**, docs/canon/**, pages/arcanea-library.js, .arcanea/** (mirroring the existing lore lint's scoping) to avoid adding CI overhead/noise to unrelated PRs.
• The lint itself is cheap (a handful of bounded regexes over added diff lines), so runtime cost per invocation is negligible — the concern above is about trigger scope/noise, not the scan itself.

Security

• No injected/interpolated shell commands; execFileSync with array args is used correctly throughout.
• No secrets or credentials touched.

Content changes

• The CANON.md / library quarantine-banner / pages/arcanea-library.js edits read as reasonable, narrowly-scoped corrections (replacing an unsupported "Celtic quantum" claim, qualifying "The Field" as in-world mechanics, adding fiction/quarantine banners) rather than deletions of prior material, consistent with the PR's stated "preserve, don't silently overwrite" approach.
• As the PR body itself notes, the canon-authority conflict (which of arcanea-lore/CANON.md, .arcanea/lore/CANON_LOCKED.md, .claude/lore/ARCANEA_CANON.md is authoritative) and the Starlight Intelligence name collision remain open — that's a governance//lock-decision call, not something this review can resolve, and the PR correctly holds itself in draft pending it.

Suggested before merge: fix or remove the starlights-species rule (or add the same negation-safety pattern used elsewhere), add a test for it either way, and narrow the workflow's paths: trigger to lore/content-related paths.