Map: the way to Mighty 0.1.0

[aminevg]

Destination

The way to Mighty 0.1.0 is clear: every design decision for the first release is locked and the execution issues are cut. 0.1.0 ships @gomighty/core, @gomighty/hono, the Laravel adapter (composer package plus its Node sidecar), create-mighty, a Laravel starter kit, and a truthful, redesigned docs site.

Notes

Domain. Vocabulary lives in CONTEXT.md at the repo root (adapter, render request, shared context, sidecar). Use it in tickets and resolutions. Grilling tickets call the grilling and domain-modeling skills. Research tickets call research. The prototype ticket calls prototype and frontend-design. Verification suite is in AGENTS.md.

Standing decisions from charting (agreed with Amine, 2026-09-11):

• Astro 7.x from the start, no intermediate 6.3 step. Node only for 0.1 (22.12+ is Astro 7's floor). Drafts chore(deps): bump dependencies and migrate to new APIs #25, test: isolate fixture state by copying per getFixture() call #26, feat(docs): revamp site with Starlight 0.39 re-skin and landing page #27 are closed.
• Per-adapter CLIs (mighty-hono, mighty-laravel) with shared helpers in core. No single mighty CLI.
• Core may depend on Astro internals for 0.1 with a pinned Astro range. Simplify only if research shows a public path.
• Laravel: composer package in packages/laravel-php, npm sidecar @gomighty/laravel in packages/laravel built on the Hono adapter. Tempest-style root composer.json and subsplit to read-only mirrors (gomighty/laravel, gomighty/laravel-starter-kit). Starter kit also lives in the monorepo.
• PHP ^8.2, Laravel 12 and 13. Pest, PHPStan, Pint. CI: Node 22/24/26; PHP 8.2–8.5 × Laravel 12/13 (valid combos only); one end-to-end job booting the sidecar through Laravel; Vitest job added.
• Sidecar: HTTP over localhost TCP. Hot-file discovery is mandatory. mighty-laravel dev|build|start is the source of truth; artisan mighty:* wraps it. Dev assets load straight from the sidecar. Build writes client assets into Laravel public/. The HTTP contract is internal transport, not a versioned protocol; other adapters build on core or Hono.
• Laravel 0.1 feature floor includes Blade <mighty:...> tags and the <CSRF>/<Method> Astro components. The Laravel docs page is the draft spec.
• create-mighty in the monorepo, must yield a good npm create mighty flow.
• Docs: describe only what ships; roadmap page is the one home for future work. Redesign starts from a blank current Starlight, logo kept, ignore feat(docs): revamp site with Starlight 0.39 re-skin and landing page #27. Add a copyable agent prompt on landing and installation pages plus llms.txt/llms-full.txt. Docs deploy on Vercel, already wired to this repo. Vocabulary renames in docs happen in the docs content pass, not before.
• Versions: npm and Composer packages identical, one v0.1.0 tag drives both. Changesets for npm.
• Competitor kill criterion: stop only if a maintained library renders .astro pages on demand from a non-Astro backend with dev HMR.

Decisions so far

• Competitor landscape: does anything already render Astro from a foreign backend?: Survey completed; native Astro Hono is a conditional match requiring runtime verification and a decision on backend ownership.

• Astro 7 upgrade impact on the internals core relies on: Audited imports survive; logger, tooling and docs migrations identified, with dev lifecycle/CSS/HMR checks required and separate runtime/build Node floors.

• Dev CSS without vendored Astro code: No public collector; private virtual CSS module identified for a runtime probe, with updated vendoring as fallback and approach/pin policy left to the decision ticket.

• What the /mighty dev base prefix is for: Reserves same-origin asset paths; Vite 8 URL behavior verified, with separate-origin, CORS and HMR trade-offs ready for the prefix decision.

• Tempest-style monorepo mechanics for PHP and JS packages: Source audit and concrete layout proposal completed; isolate starter installs, map split paths explicitly, and split the selected release commit.

• Laravel adapter building blocks: Laravel mechanisms verified; PHP 8.2 needs separate test tooling, while partial-render assets and request/context forwarding remain spec decisions.

Not yet specified

• Test strategy for the Laravel packages: Testbench or a real skeleton app, and what the end-to-end CI job actually boots. Sharpens after the sidecar and monorepo tickets.
• How Astro dev errors surface when the page is rendered by PHP (error overlay, stack traces). Depends on the sidecar design.
• What core exports as shared CLI helpers for per-adapter CLIs. Depends on the Hono API and sidecar tickets.
• How create-mighty handles a Laravel project (composer plus npm in one flow). Depends on the Laravel spec.
• Roadmap page content for 0.1 (Actions, Sessions, SPA mode, file-based routing, scaffolders, runtimes). Settles in the docs content pass.

Out of scope

• Bun, Deno, and Cloudflare Workers support. Workers needs its own consideration after 0.1.
• Unix-socket transport for the sidecar.
• Bypassing the sidecar for prerendered components.
• Infra guidance (supervisor, systemd) in docs.
• The fixture-isolation approach from test: isolate fixture state by copying per getFixture() call #26.
• A versioned public HTTP protocol for the sidecar.