P0: Vedic (Jyotish) architecture & source-matrix freeze (ADR 0013, Proposed)

[Jowitt13]

P0: Vedic (Jyotish) architecture & source-matrix freeze (ADR 0013, Proposed)

Docs-only slice that freezes the engineering boundaries for the fourth first-class system
(vedic) before any code. No calculation code, contracts, CLI, lockfile, SBOM, dist bundle
or golden values change (verified byte-identical after a full verify:cloud including build).

What this PR contains (6 files)

• docs/adr/0013-vedic-architecture.md (new) — Status: Proposed — P0 architecture
  complete; semantic defaults awaiting owner confirmation.
  • Frozen engineering boundaries: system id vedic + @ming/vedic / @ming/vedic-rules
    package split; geocentric apparent ecliptic-of-date frame on the existing astronomy-engine
    base; Lahiri precisely identified as the IAE-1985 standard (Swiss SE_SIDM_LAHIRI, never
    conflated with True Chitra Paksha or Lahiri ICRC — goldens pinned to swetest -sid1);
    Ketu = Rahu + 180° exactly; whole-sign bhava only (structured warning for Chalit);
    27-nakshatra scheme with left-closed right-open intervals; instantaneous panchanga
    formulas; D1/D9 Parashari mapping; canonical-rounding classification policy; timeAccuracy
    degradation table; v0.3.0 public-contract break plan (PublicResult.systems 3→4, contract
    v2) and the P1–P6 PR roadmap.
  • Proposed / blocked (NOT decided): mean-Rahu default (proposed, owner confirmation
    pending); sunrise rule target upper-limb (astronomy-engine 2.1.19 source evidence recorded:
    top-edge semantics + apparent angular radius + fixed 34′ refraction; exact mapping to the
    classical −50′ center convention is an explicit P2/P3 blocker); Vimshottari year model —
    BLOCKED on owner decision (candidate julian-365.25; P3 additionally gated on a
    same-model dual-implementation cross-check; P1 may reserve the enum but wires no default).
• docs/VEDIC_SOURCE_MATRIX.md (new) — per-topic registry (adopted definition, primary +
  secondary sources, school disagreements, license status, future implementation file, external
  golden method, acceptable error, unresolved questions). Traditional rule sources (BPHS, Surya
  Siddhanta — public domain, chapter-cited) kept separate from modern astronomical sources
  (IAE, Swiss docs as reference documentation, astronomy-engine, Meeus). Binding license
  boundary: Swiss Ephemeris = external golden generator only; PyJHora = research-only;
  node-jhora = fully excluded; jyotishganit / VedAstro = independent cross-check only.
• docs/RULESETS.md — adds vedic-parashara-lahiri@0.1.0 as PLANNED, not implemented.
• tools/vedic-docs.test.ts (new, 7 tests) — doc gate: P0 deliverables + required sections
  present; ADR status must stay Proposed with the year-model/sunrise blockers intact; Skill
  surfaces must not claim any vedic/jyotish capability before the P5 slice ships.
• docs/STATUS.md / docs/VALIDATION.md — test-count lines only, from a real run
  (692 tests / 35 files); byte-level patch, no other content touched.

Verification (all green, local)

• pnpm install --frozen-lockfile → already up to date (lockfile untouched)
• pnpm run verify:cloud → all 18 stages pass: format:check, lint, typecheck,
  test (692/35), build, validate:provenance, validate:skill 40/40, validate:reading 53/53,
  validate:docs 134/134, smoke, forward:test, package:hosts, verify:hosts,
  verify:install 106/106, check:doc-counts 12/12, scan:deps (0 advisories),
  scan:licenses 20/20, validate:sbom 96/96, scan:secrets
• git diff --check clean; pnpm-lock.yaml, sbom.*.json, scripts/dist/,
  packages/western/goldens/ byte-identical to main

Explicitly out of scope

No merge decision, no tag, no Release, no manifest promotion, no engine-version change. All
inputs referenced in the plan are synthetic; no real birth data anywhere.

Owner decisions requested (ADR "Open questions")

1. Rahu default mean (proposed) — confirm?
2. Vimshottari year model (BLOCKING P3) — candidate julian-365.25 vs savana-360 vs sidereal.
3. Sunrise rule target upper-limb (proposed) — confirm? (backend mapping verified in P2)
4. v0.3.0: flip default systems to 4, or keep vedic opt-in?
5. Public contract v2: hard cut in v0.3.0 (recommended) vs dual-emit v1+v2.