petrova.blue is the apex, and it ships as a fourth surface in this repo

Date: 2026-08-06 Status: open Supersedes: none Superseded-by: none — current Implements: docs/specs/2026-08-05-petrova-apex-domain-topology.md §1–§2

Context

The petrova set had four candidate apexes and no front door. PETROVA-APEX §1 rules the apex to petrova.blue on the grounds that it is the only surface with no incumbent reader: it can hold a scene without displacing anything, and it carries zero redirect debt. petrova.blog keeps its landing, petrova.codes keeps its machine contract, petrova.host is untouched by this doc.

That ruling was recorded as blocked on a purchase. It is not. petrova.blue was registered 2026-08-05, the day the spec was drafted — verified via RDAP, which reports a registration event on that date. The APEX §5.1 risk (“£12, unverified availability, everything in §2 is void if it is taken”) is resolved in our favour and needs no further action.

What the domain currently serves is a Hostinger parked page (server: hcdn, title “Parked Domain name on Hostinger DNS system”). Registered, DNS pointing at the registrar’s parking, nothing of ours on it.

Decision

1 — The apex landing is built as blue/, a fourth Astro app in petrova-codes.

The estate has two competing precedents. stratt.blue and devarno.blue are each their own repository. But this repo already deploys three Vercel projects from three subdirectories — site/ → petrova.blog, dashboard/ → petrova.host, codes/ → petrova.codes. For the petrova set specifically, one-subdir-per- surface is the established pattern, and it is the one with no new repository, no new CI, and no submodule to bump. A fourth Vercel project reads blue/.

2 — The page is APEX-LANDING, not a new design.

Vertical order: mark · wordmark · scene · table. Nothing else above the fold, nothing below on first ship. The visual tokens are arno’s own, taken from the live surface rather than approximated — the same slate ground, oxide accent, sans/mono pair, 46rem measure. Per APEX-LANDING §1 the recognisability of the format is itself the asset, so a lookalike palette would defeat the point.

Scene copy is §2 verbatim, unedited. Table is the four rows §2 specifies: blog, host, codes, and status.petrova.blue badged planned. The planned row carries no link, because a badge next to a working link is decoration.

3 — The mark is drawn to §2’s specification.

Three concentric rounded rectangles; the outer two open on the right edge, the innermost closed. A single oxide dot sits on the innermost boundary line — the write arriving at the gate, not past it. The two gaps are aligned with the dot so the path inward reads as one aperture. §2’s rejections are honoured: no shield, no padlock, no gear, nothing anthropomorphic, no Cyrillic pun.

4 — What is deliberately absent.

No npx line, no boundary diagram, no CTA, no nav chrome, no metrics widget — each named in §2, each belonging to a surface whose reader has already decided. No line explaining the boundary: the scene is the boundary.

Alternatives considered

• Fold the landing into petrova.blog and skip the domain. This is APEX §1’s recorded alternative. It costs ~90 URL rewrites, an llms.txt regeneration, and it moves the estate’s most-linked path. Rejected there and rejected here; nothing has changed except that the domain now costs nothing because it is already owned.
• A separate petrova-blue repository, matching devarno-blue and stratt-blue. Rejected for this set: petrova’s three existing surfaces all ship from this repo, and a fourth repo would add a CI surface and a release path for one static page.
• Serve it from the existing site/ build under a second domain. Rejected: §1’s whole argument is that a corpus apex cannot hold a scene. Sharing the build would re-import the nav chrome the format forbids.

Consequences

The page is built and verified locally, but petrova.blue does not serve it yet. Two steps remain and neither is a code change:

1. Create a Vercel project pointing at blue/ in this repository.
2. Move petrova.blue DNS off Hostinger parking to that project.

Until both land, this decision is implemented in the repo and invisible on the internet. That is why this doc is open rather than closed.

Still gated elsewhere, unchanged by this decision: the petrova.host re-root (APEX §3, wants its own decision doc), the reciprocal nav link (APEX §4 item 3, blocked on the 2026-05-13 cross-platform nav contract still being open), and the MR-numbering reconciliation (APEX §5.3). No copy on this page cites an MR by number, per §5.3.

Sign-off

• Human countersign — apex ruling and the two infrastructure steps above.