Astrology12 MIN READ41 / 116

Vedic engine tasks

Modules share the Vedic domain package. Read the module specifications and current package boundaries for source ownership and public APIs. Authority: Vedic HLD; detailed calculation HLDs are linked per task. See parallel assignment. Implementation status (2026-10-25): the calculation modules are implemented. Criteria that need external review or upstream work remain open and are not claimed:

Task Open criterion
V-02, V-09, V-11 Resolved in parashari-core@2: BPHS/Surya Siddhanta judgments (exaltation spans, node signs, northern-latitude war), Phaladeepika gochara (transits from the natal Moon)/vedha, Muhurta Chintamani ashtakoota with the 15° vashya split; fixtures in the owning modules
V-07 Resolved: BPHS ch. 66 table ships as PARASHARI_BAV_RULES; trikona/ekadhipatya reductions implemented against F-AV4
V-08 The 30-day, two-city published almanac comparison; native rise/set B-01 → C-05 is now available for host wiring
V-10 Station-adjacent fixtures against real ephemeris data
V-12 Resolved: the parashari-core@1 pack ships with named sources per rule
V-14 P3 named primary source for yatra@1; the pack ships with status: 'draft'
V-06 Resolved: SB-V5 epoch is 1 January 1860 (reproduces F-SB15), E4 reads “lowered”; SB-V1/SB-V4 are selected by parashari-lahiri@2
V-19 Independent reference-chart fixtures; only shadbala-partial (Shadbala) is advertised

Upstream gaps are connected through the upstream package rather than worked around. Write scopes are repository-relative and include each module’s source, tests, owned tables/fixtures, README and public exports. Shared contracts and registries have separate owners; leaf agents do not edit their implementation.

V-01 — Implement the profile catalog

HLD: component map, convention register. Depends on: V-16, S-01. Write scope: packages/vedic/src/**.

Pin ayanamsa (the sidereal offset), house/frame convention, body/node selection, varga scheme, dasha year length, drishti policy and rule-table identities in immutable profiles.

Acceptance criteria:

  • [ ] Initial profile records every relevant convention and source; unresolved variants are excluded from capabilities.
  • [ ] Position origin is explicit and independent of the house observer; supplying a birth location never silently changes the position model.
  • [ ] Unknown profiles and incompatible versions fail with the HLD’s named errors; rulebook identities are explicit and never substituted.
  • [ ] Profiles select family/variant IDs but do not load or duplicate numerical rule tables; V-17 owns bundle integrity and each feature owns its rules.
  • [ ] Drishti convention identifies the policy validated by V-18; profile resolution never invokes drishti calculations.

V-02 — Implement D1 judgments

HLD: chart judgments, chart-core rules and edge cases. Depends on: V-01. Write scope: packages/vedic/src/**.

Implement dignity, combustion and planetary war over Composer facts. Frame/rosters remain C-02.

Acceptance criteria:

  • [ ] Own/exalted/debilitated/moolatrikona/friendship states match reviewed table fixtures, including exact degree boundaries.
  • [ ] Motion-aware combustion uses the selected orb table; absent Sun makes the layer unavailable rather than false.
  • [ ] Eligible war pairs, equal-longitude outcomes and node/luminary exclusions follow named rules; indeterminate outcomes remain explicit.
  • [ ] Every judgment retains deciding rule IDs and input facts; no chart geometry or Binder read is reimplemented.

V-03 — Implement D9 and vargottama

HLD: varga responsibilities, rules. Depends on: V-01, C-02 for shared frame/roster primitives. Write scope: packages/vedic/src/** (D9 slice).

Acceptance criteria:

  • [ ] Movable/fixed/dual sign fixtures match the named D9 scheme; each part boundary is tested below, exactly at and above it.
  • [ ] Bodies and lagna (ascendant) use one D1-to-D9 mapping; D9 houses derive from mapped signs.
  • [ ] Vargottama is exactly D1 sign equals D9 sign; no fabricated varga degrees are returned.
  • [ ] Tropical input and unsupported IDs fail; D1 is passed through unchanged and no extra astronomy is requested.

V-04 — Complete all sixteen vargas

HLD: varga input/output contract, edge cases. Depends on: V-03. Write scope: packages/vedic/src/** (remaining vargas; starts after V-03 handoff).

Acceptance criteria:

  • [ ] All sixteen catalog entries have named schemes and independent expected mappings; every sign’s span has total coverage without gaps/overlap.
  • [ ] D2 reversal, unequal D30 spans and each documented variant are exercised under the selected tables; no variant is inferred silently.
  • [ ] Each requested varga comes directly from Binder-returned D1 without another rounding step, including lagna; output follows natural varga/body order.
  • [ ] Missing or malformed scheme rows fail load; unknown requested IDs fail admission rather than being skipped.

V-05 — Implement Vimshottari timeline and lookup

Vimshottari is the 120-year nakshatra-based dasha cycle.

HLD: dasha rules, edge cases. Depends on: V-01. Write scope: packages/vedic/src/**.

Acceptance criteria:

  • [ ] Birth balance preserves Binder-returned Moon longitude and normalization provenance and uses Binder nakshatra ID; missing/inconsistent Moon facts fail.
  • [ ] Nine unique lords sum to 120 years; year-length profile identity appears in results, including supported alternative-year fixtures.
  • [ ] Default depth 3 and requested depths 2–4 work; depth 5 fails. Cumulative subdivision produces children that tile parents with identical shared boundaries.
  • [ ] Nominal first-period start, partial balance and exact-boundary active chain match reviewed fixtures; pre-start lookup is empty and later cycles report their index.
  • [ ] Dates are UTC instants rounded once at output; no clock/calendar/timezone input affects arithmetic.
  • [ ] Children subdivide the full nominal parent, not the remaining balance; 359.9999° uses Binder’s Revati ID and only canonical 0° enters Ashwini. Boundary fixtures enforce the corrected HLD wording.

V-06 — Specify strength systems and required inputs

HLD: strength component and gates, capability gates. Depends on: V-01. Write scope: strength specifications/fixtures under docs/astrology/vedic-engine/; no runtime export yet.

Acceptance criteria:

  • [ ] Each proposed strength system lists formulas, convention variants, rule sources, output factors and required astronomical/chart inputs.
  • [ ] Every input maps to an existing Composer field or a named missing upstream capability; absent quantities are not inferred.
  • [ ] Shadbala gets a dedicated definition and reviewed factor fixtures before V-19 implements that system; undefined systems stay gated.
  • [ ] Scope identifies which factors can ship independently and what makes a full-system result complete.

V-07 — Implement natal ashtakavarga

Ashtakavarga scores each sign by benefic points (bindus) contributed from natal positions.

HLD: ashtakavarga responsibilities, rules. Depends on: V-01, V-06’s ashtakavarga definition. Write scope: packages/vedic/src/**.

Acceptance criteria:

  • [ ] BAV/SAV are computed from immutable natal facts and named contribution/reduction tables; reviewed BAV fixtures pass.
  • [ ] The specified unreduced SAV total is 337; invalid contribution tables fail load. Any reduction convention states its stage so the invariant is not incorrectly applied after reductions.
  • [ ] A transiting sign reads the natal BAV; it never recomputes BAV from moving positions.
  • [ ] Bodies without BAV return unavailable/null when queried, not zero; factors retain their source chart and rulebook identity.

V-08 — Implement sunrise-based panchang

The panchang is the Vedic almanac day of five limbs.

HLD: panchang rules, edge cases, delivery validation. Depends on: V-01, C-04, C-05. Write scope: packages/vedic/src/**.

Acceptance criteria:

  • [ ] Day/vara use [sunrise, nextSunrise); all five limbs (vara, tithi, nakshatra, yoga, karana) and at-sunrise values are returned with solved UTC boundaries.
  • [ ] Tithi/karana are invariant under an ayanamsa change; nakshatra follows Binder IDs and yoga follows the selected sidereal convention.
  • [ ] Boundary residual is within the HLD’s one-second tolerance; missing speed uses bounded bisection; exhausted probes fail rather than approximate.
  • [ ] Kshaya/adhika (skipped/repeated tithi), exact-sunrise changes, 0°/360° wrap and fixed/movable karana cycle fixtures pass.
  • [ ] Missing sunrise/next sunrise fails even with partial requested; missing sunset remains null.
  • [ ] Results match a convention-compatible published almanac for 30 consecutive days in two cities, with sources/tolerances recorded and disagreements explained.
  • [ ] Before implementation, freeze the host-resolved day-window/offset input for DST and distinct consecutive-day offsets; do not infer a fixed 24-hour day from a single local-date label.

V-09 — Implement point-in-time gochara and Sade Sati state

HLD: transit contract, rules. Depends on: V-01, C-02; V-07 only when bindus are requested. Write scope: packages/vedic/src/** (snapshot mode).

Acceptance criteria:

  • [ ] Explicit asOf and admitted immutable reference are required; missing Moon and mismatched profile/rulebook/Binder identities fail.
  • [ ] Gochara uses natal Moon sign; lagna placement is separately labelled and never substitutes for it.
  • [ ] Selected Sade Sati basis and vedha tables govern output; base and effective verdict plus cancelling pair remain visible.
  • [ ] Unrequested BAV is omitted; requested unsupported BAV is unavailable explicitly. No natal chart is recomputed.

V-10 — Implement transit windows and phase intervals

HLD: transit edge cases. Depends on: V-09 and C-04’s bounded series/probe capability. Write scope: packages/vedic/src/** (window mode; starts after V-09 handoff).

Acceptance criteria:

  • [ ] Output is ordered occupancy segments/events with solved ingress boundaries, not daily samples labelled exact.
  • [ ] Retrograde re-entry produces separate intervals; enter-and-leave within a scan step and station-adjacent crossings have reviewed fixtures.
  • [ ] Half-open window edges have no duplicate events; clipped Sade Sati phases retain started-before/continues-after flags.
  • [ ] Invalid/oversized windows and too-small steps fail before reads; exhausted search and upstream range errors preserve the documented outcome.

V-11 — Implement ashtakoota matching

HLD: matching rules, edge cases. Depends on: V-01, C-01 snapshot/reference format. Write scope: packages/vedic/src/**.

Acceptance criteria:

  • [ ] Both subjects pass Moon sign/nakshatra/pada and version checks; tropical/inconsistent references fail without recomputation.
  • [ ] All eight kootas return in HLD order with exact points, maximum, basis and verdict; maxima sum to 36 and exact total 18 meets the pinned threshold.
  • [ ] Reversing pair direction exercises ordered kootas; identical subjects remain valid.
  • [ ] Nadi/Bhakoot cancellations retain present/cancelled/rule evidence; cancellation does not silently award points or erase the dosha.
  • [ ] Invalid/missing matrix entries fail load; no Binder access or birth-data requirement enters this pure calculation.
  • [ ] A consumer can import matching alone and evaluate supplied Moon facts/rules without constructing an engine or importing other calculators/native providers.

V-12 — Define and implement a named yoga/dosha pack

A yoga is a named planetary combination; a dosha is a named affliction.

HLD: chart judgments, ownership. Depends on: V-01, V-02 and V-18’s drishti result types; additional dependencies declared by the chosen pack. Write scope: packages/vedic/src/** and its pack specification.

Acceptance criteria:

  • [ ] Specification enumerates the exact rules, required facts, exceptions and sources before implementation; “all yogas/doshas” is not an accepted scope.
  • [ ] Each selected rule has positive, negative, cancellation and missing-input fixtures where applicable.
  • [ ] Results retain deciding facts, rule IDs and cancellations; no interpretation/remedy text is generated.
  • [ ] Unsupported packs are rejected and no matching-only Moon contract is reused for Mars-dependent doshas.

V-13 — Specify the first muhurta purpose pack

Muhurta is the selection of an auspicious time window for a purpose.

HLD: muhurta component/interface, muhurta research. Depends on: V-01. Write scope: muhurta pack specification/fixtures under docs/astrology/vedic-engine/.

Acceptance criteria:

  • [ ] One named purpose has explicit inclusion/exclusion predicates, precedence, required panchang/judgment facts and source references.
  • [ ] Window limits, interval boundary/merge rules and empty-result behavior are specified with expected examples.
  • [ ] Every factor maps to V-08 or an identified judgment pack; missing prerequisites are listed before scheduling V-14.

V-14 — Implement the specified muhurta pack

HLD: muhurta ownership, V-13’s completed specification. Depends on: V-13, V-08, V-02’s judgment result types and any additional tasks selected in V-13. Write scope: packages/vedic/src/**.

Acceptance criteria:

  • [ ] Accepted intervals and excluded candidates match pack fixtures and carry per-rule reasons.
  • [ ] Calculation reuses panchang intervals and judgment results; sunrise/limb calculations are not duplicated.
  • [ ] Window/probe limits fail before excessive work; exact boundary and no-accepted-window cases are deterministic.
  • [ ] Unknown purposes and unavailable factors fail explicitly; named pack/version appears in results.

V-15 — Wire coordinator, capabilities and evidence

HLD: proposed interface, gates/failures. Depends on: V-16, V-01, V-17, C-09 and first-slice feature contracts V-02/V-03/V-05/V-18; add each later feature as delivered. Write scope: packages/vedic/src/**.

Acceptance criteria:

  • [ ] Only requested layers and prerequisites execute; a dasha-only operation does not require unrelated houses/strengths.
  • [ ] Engine accepts registered feature instances; importing/constructing a minimal engine does not import every calculator or Binder implementation.
  • [ ] Per-feature rule hashes match the admitted bundle, and an unregistered feature produces unsupported capability rather than an empty success.
  • [ ] One profile/rulebook applies per response; results retain rule IDs, snapshot/probe references, engine/Composer versions and Binder evidence.
  • [ ] Default failure is complete failure; opt-in partial output lists unavailable layers and dependents. V-08 retains its stricter no-partial rule.
  • [ ] Capabilities reflect implemented variants and upstream facts; every added operation updates coordinator tests and the supported-feature list.
  • [ ] Engine build, type checks and tests pass using an injected Composer port, without native ephemeris files or live provider HTTP.

V-16 — Publish shared Vedic contracts

HLD: shared response and capability boundary, component map. Depends on: C-01, S-01. Write scope: packages/vedic/src/**.

Implement the contract exports; each calculator defines its own detailed request/result/rule schema, while this package defines shared identities, requirements and feature envelopes.

Acceptance criteria:

  • [ ] Public profile, bundle, result, feature and capability types cover the HLD’s shared fields without importing calculators/registries/engine.
  • [ ] Feature requirements describe needed chart facts/ports, rule-family identity and dependency results; sync/async wrappers are unambiguous.
  • [ ] Independent dasha, matching and engine consumer examples type-check against the same contracts.
  • [ ] Importing the contracts has no runtime effects or native/provider dependencies.

V-17 — Implement rulebook bundle admission

HLD: profile/rulebook ownership, one rulebook per response. Depends on: V-16, C-09. Write scope: packages/vedic/src/**.

Implement the registry exports with supplied typed family resources; feature rules stay under their owning calculator package’s src/rules/.

Acceptance criteria:

  • [ ] Manifest, family IDs and content hashes validate before a handle is served; duplicate/missing/tampered families fail explicitly.
  • [ ] Typed lookup invokes the supplied family validator; no unchecked cast invents a valid rule schema.
  • [ ] Profile compatibility and one-bundle identity are preserved across all requested features.
  • [ ] Registry imports neither feature implementations nor engine; isolated tests use small supplied bundles.

V-18 — Implement the drishti policy package

HLD: Vedic drishti ownership, base semantics reuse. Depends on: V-16, V-01 convention selection. Write scope: packages/vedic/src/**.

Implement the drishti exports as policy-aware relationships over the existing semantics primitive. Do not move or copy the primitive during this task.

Acceptance criteria:

  • [ ] Classical seventh and Mars/Jupiter/Saturn special counts match reviewed sign-based fixtures.
  • [ ] Node rules require an explicitly selected school; missing rules remain unknown/unserved rather than a fabricated empty match.
  • [ ] Directed source/sign/target identities and deciding policy/rule IDs survive output.
  • [ ] Existing resolveDrishti is reused; no angular-aspect or sign-assignment implementation is duplicated.

V-19 — Implement an audited strength system

HLD: strength capability gate, V-06’s completed system definition. Depends on: V-16, V-06 for that system and its explicitly audited upstream/factor prerequisites. Write scope: packages/vedic/src/**.

Implement only the system whose formulas, requirements and reference fixtures V-06 has resolved.

Acceptance criteria:

  • [ ] Each factor and aggregate matches the approved independent fixtures within named tolerances.
  • [ ] Required absent quantities fail completeness checks; neither zero nor an inferred total hides a missing factor.
  • [ ] Supplied varga/BAV/judgment results retain source/version compatibility; dependencies are declared from the selected definition rather than importing every Vedic package.
  • [ ] getStrengthRequirements and capabilities list exactly the implemented system/variants; unreviewed Shadbala remains unavailable.