Skip to content

Add Western Persona Chart endpoint; complete house-system name map - #1

Merged
dubeychandan996 merged 1 commit into
mainfrom
feat/persona-chart
Sep 17, 2026
Merged

dubeychandan996 merged 1 commit into
mainfrom
feat/persona-chart

Conversation

@dubeychandan996

Copy link
Copy Markdown
Collaborator

Adds the Persona Chart endpoint for DV-326. Companion PRs in divineapi-python, divineapi-node, and Dinesh-Gahlot/mcp-western-astrology.

What this adds

NatalApi::personaChart() → POST /western-api/v1/persona-chart on astroapi-8. Casts the full chart for the exact moment — within the first year of life — that the transiting Sun reaches the natal degree of the chosen persona_planet.

$result = $client->western()->natal()->personaChart(
    $westernBirth + ['persona_planet' => 'moon']
);

Optional params pass through in the array: node_type (meannode | truenode), output_include, graphic_layout and the other chart-appearance / aspect options.

House system — this SDK was the one that got it right

The sibling SDKs both raise on unknown house_system values from a whitelist that was missing 7 of the API's 16 Swiss Ephemeris codes (A, D, V, X, S, T, N). That rejected the Persona Chart docs' own example, house_system="A".

PHP was never affected, because HouseSystem::resolve() returns unknown values unchanged and lets the API arbitrate — exactly as its docblock says. Worth noting as the pattern the other two should probably converge on.

What was missing here were friendly names: the map only covered 9 of the 16 systems, so 'sripati' or 'equal-asc' were forwarded verbatim instead of resolving to S and A. This PR adds the missing names and makes VALID_LETTERS explicit for all sixteen codes. Verified 2026-09-14 on both astroapi-4 and astroapi-8.

Response size

output_include defaults to raw_data server-side (~21 KB, data only). Measured: one *_svg token is ~494 KB and all returns ~4.3 MB.

Testing

HouseSystem::resolve() verified for letters, lowercase, and all the newly added friendly names. Live end-to-end call confirmed: 18 planets, 12 houses, plus a second call exercising a friendly house-system name + node_type + uppercase persona_planet.

No version bump — this repo carries no version field in composer.json; Packagist reads git tags, so tag on merge.

🤖 Generated with Claude Code

NatalApi::personaChart() -> POST /western-api/v1/persona-chart on
astroapi-8. Casts the full chart for the exact moment within the first
year of life that the transiting Sun reaches the natal degree of the
chosen persona_planet.

Optional params pass through in the params array: node_type,
output_include, graphic_layout and the other chart-appearance and
aspect options. output_include defaults to raw_data server-side
(~21 KB); image tokens are ~0.5 MB per SVG and "all" returns ~4.3 MB.

HouseSystem already passed unknown values through unchanged, so letter
codes such as "A" were never broken here - unlike the Python and Node
SDKs, which raised on them. What was missing were friendly names: the
map only covered 9 of the 16 systems, so "sripati" or "equal-asc" were
forwarded verbatim instead of resolving to S and A. Added the missing
names and made VALID_LETTERS explicit for all sixteen codes. Verified
2026-09-14 on astroapi-4 and astroapi-8.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@anubhav-dir

Copy link
Copy Markdown
Collaborator

Findings

🟡 Medium — tests/ is wired up in tooling but doesn't exist, repo-wide

composer.json's autoload-dev maps DivineApi\Tests\ → tests/, and phpunit is a declared dev dependency, but the tests/ directory has never existed in this repo (confirmed via the GitHub contents API, not just absent from this PR's diff). The PR body claims HouseSystem::resolve() was "verified for letters, lowercase, and all the newly added friendly names" plus a live end-to-end call — none of that is checked in. Same systemic gap as the other three companion repos, but slightly more pointed here since the test scaffolding is already declared and simply never used.

ℹ️ Info — no client-side output_include size guard, consistent with sibling SDKs' design

personaChart(array $params) passes output_include straight through with no validation — a caller can request 'all' (~4.3 MB) uncontested. Same shape as divineapi-python and divineapi-node; appropriate for a raw SDK (data lands in the caller's own process), unlike the MCP server flavor which needs the guard to protect an LLM's context window. Not a regression.

✅ Verified: this repo's "we were never affected" claim holds up

Read the pre-PR HouseSystem::resolve() directly rather than taking the PR body's word for it — the passthrough-on-unknown behavior is real and predates this PR. Worth flagging positively: this is the one companion PR where a claimed pre-existing invariant was actually checked against the old source, not just repeated.

✅ #139 Persona Chart docblock number is correct, not a stray artifact

NatalApi.php's class docblock states its methods are numbered #118-127 (astroapi-4) and #128-138 (astroapi-8); every existing method has a matching sequential * #NNN Title docblock, ending at #138 Dominants. The new method's #139 Persona Chart correctly continues that existing internal catalog numbering — checked this specifically since it could easily have been a copy-paste leftover from an unrelated ticket number, but it isn't.

✅ No equivalent of the MCP repo's "stale schema description" bug

Grepped every other Western API file (CompositeApi.php, SynastryApi.php, TransitApi.php, PlanetReturnsApi.php, PrenatalApi.php, ProgressionsApi.php) — none duplicate the house-system option list as hardcoded text; SynastryApi.php's one docblock mention is already abbreviated with "...". Single source of truth in HouseSystem.php, correctly updated.

@dubeychandan996
dubeychandan996 merged commit 289d1b2 into main Sep 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants