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
asOfand 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
resolveDrishtiis 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.
- [ ]
getStrengthRequirementsand capabilities list exactly the implemented system/variants; unreviewed Shadbala remains unavailable.