is ever regenerated by /update-site. -->

SYZYGY — Package, version and share integration knowledge

Skip to content

Focus orbits<br>Exit

syzygy /ˈsɪz.ɪ.dʒi/

The alignment of three or more celestial bodies along a straight line — the geometry behind eclipses, solar transits, and spring tides. The dashed line marks each alignment axis as it forms.

bodies shown orbit · viz

Sun (Sol)—

Mercury4 m 35 s

Venus11 m 44 s

Earth19 m 05 s

Moon (Luna)1 m 26 s

Mars35 m 54 s

Phobos1.0 s

Deimos4.0 s

Jupiter3 h 46 m

Io5.5 s

Europa11 s

Ganymede22 s

Callisto52 s

Saturn9 h 22 m

Mimas3.0 s

Enceladus4.3 s

Tethys5.9 s

Dione8.6 s

Rhea14 s

Titan50 s

Hyperion1 m 07 s

Iapetus4 m 09 s

Uranus26 h 44 m

Miranda ⇵4.4 s

Ariel ⇵7.9 s

Umbriel ⇵13 s

Titania ⇵27 s

Oberon ⇵42 s

Neptune52 h 25 m

Proteus3.5 s

Triton ↺18 s

Nereid18 m 49 s

time compression

Every body obeys Kepler's third law (T² ∝ a³). Phobos anchors the clock at one orbit per viz-second; all other speeds follow.

ratio1 : 27,562

1 viz-sec≈ 7 h 39 m real

1 viz-min≈ 19.1 days real

design notes

Distances compressed (√-scaled) — true scale would make inner planets invisible.

All planets share the ecliptic plane; real orbital inclinations are not shown.

"Alignment" lines are 2-D projection artefacts — not true 3-D syzygies.

SYZYGY

(siz-ih-jee)

Align every artefact — from requirements to results

Integration knowledge<br>as code.

Your team's integration knowledge lives in a Postman collection, a stale Confluence page, and one senior engineer's head. SYZYGY turns it into a versioned plugin your whole organisation installs — with AI-authored tests, deterministic execution, and a requirements-traceability matrix that's always current.

Test at any level — component, integration, E2E — from the same artefacts. Switch environments with one flag. Nothing duplicated, nothing drifting.

Runs entirely on your own machine or CI runner: your payloads, credentials, and results never leave your network. Free to use, including commercially.

~/projects/checkout-api<br>syz · latest

$ syz generate plugin --name payments --guide-only<br>✓ PLUGIN-GUIDE.yaml<br>✓ plugin.yaml<br>✓ CLAUDE.md<br>✓ Guide-first plugin shell created — record behaviour before any<br>endpoint exists. Fill in .syz/plugins/payments/PLUGIN-GUIDE.yaml.

$ cd .syz && claude<br>● Claude Code ~/projects/checkout-api/.syz<br>> Add two rules to the payments guide: creating a payment must be<br>idempotent on the Idempotency-Key header, and amount must be a<br>positive integer in minor units.<br>● I'll record those in the plugin guide.<br>● Update(plugins/payments/PLUGIN-GUIDE.yaml)<br>⎿ Updated with 8 additions<br>+ - id: REQ-PAY-003 (idempotent on Idempotency-Key)<br>+ - id: REQ-PAY-004 (amount = positive integer, minor units)<br>● Added REQ-PAY-003 and REQ-PAY-004. Run `syz lint` to validate.

$ cd .. && syz generate plugin --name payments --from openapi:./payments-api.openapi.yaml --yes<br>Building artifacts for 2 operation(s)…<br>✓ procedures/send_create_payment.yaml<br>✓ procedures/create_payment_send_success.yaml<br>✓ procedures/send_get_payment_status.yaml<br>✓ procedures/validate_send_no_error.yaml<br>✓ data.yaml — written<br>⚠ PLUGIN-GUIDE.yaml — preserved (user-owned)<br>✓ Generated 2 operation(s) on the same folder.

$ cd .syz && claude<br>> Write an e2e scenario for payments: create a payment, then poll<br>its status until it settles. Use PLUGIN-GUIDE.yaml and the procedures.<br>● Write(scenarios/e2e/payment_flow.yaml)<br>⎿ Wrote 41 lines — covers: [REQ-PAY-001, REQ-PAY-003, REQ-PAY-004]<br>> Base URL https://api.payments.example.com/v1, token in<br>$PAYMENTS_TOKEN, customer cust_alice, amount 5000 GBP.<br>● Update(environments/dev.yaml) + base_url, + auth_token (masked)<br>● Update(plugins/payments/data.yaml) + customer_id, amount, currency

$ cd .. && syz run --suite .syz/scenarios/e2e --env dev<br>▶ e2e/payment_flow — Create then settle a payment<br>─── STEP 1 of 3: send — payments.send_create_payment ───<br>→ POST https://api.payments.example.com/v1/payments<br>← 201 Created<br>✓ Response status is 201 [http · equals · $.fields.status_code]<br>✓ SUCCESS 245ms<br>─── STEP 2 of 3: workflow (poll ≤5) — payments.get_payment_status ───<br>↻ attempt 1 of 5 ✗ status settled? — "pending"<br>↻ attempt 2 of 5 ✓ status settled?<br>✓ POLL CONVERGED 2/5 attempts 1120ms<br>─── STEP 3 of 3: validate — payments.validate_create_payment ───<br>✓ Payment id present [json · exists · $.fields.body.id]<br>✓ Amount echoed [json · equals · $.fields.body.amount] → 5000<br>✓ SUCCESS 14ms

1 passed of 1 3.51s<br>Results: .syz/results/run-2026-07-04T10-53-00-000Z<br>✓ All scenarios passed — open the auditable report:<br>file://.syz/results/run-2026-07-04T10-53-00-000Z/index.html

$ syz rtm --lastrun

✓ wrote .syz/rtm.md<br>✓ 0 uncovered requirements<br>✓ 0 dangling covers: references

$ cat .syz/rtm.md<br># Requirements Traceability Matrix (RTM)

> Derived report — generated by `syz rtm`. Do not hand-edit;<br>> set `covers:` on your tests and regenerate.<br>> Outcomes from the latest run: run-2026-07-04T10-53-00-000Z

| Requirement | Covered by |<br>|---|---|<br>|...