Aporia PR sync

Onboarding is a one-time bootstrap; this is the heartbeat. A codebase changes every PR, and the map is only worth trusting if as_built tracks the code continuously. This skill is the map's repo-facing half: a diff-scoped re-scan that keeps the structure objective and, crucially, re-derives whether each touched feature reads Built as the code that backs it lands or disappears.

Run it before opening a PR (preview the delta the change creates) or after a merge (record the new as-built truth). It is idempotent and key-reconciled — re-running converges, never duplicates.

The bar

The same Recognition Test as onboarding, plus one sync-specific line: after a sync, every feature the PR touched reads its true Built state — Built only if the code really carries it, Not built if it's still just intent. A sync that leaves a feature reading Built when no code carries it has failed.

The hard line is unchanged: report structure with evidence; never fabricate intent. Sync touches as-built reality — it never authors the why. It may carry a why a human actually stated (Phase 5's post-merge capture, which cites its source); supplying one nobody stated is fabrication. Preserve authored intent and notes verbatim; a re-scan that rediscovers an authored node realizes it, it does not clobber it.

The Built axis (what your scan controls)

Built is BINARY and scan-owned: a feature is Built when it is as_built AND carries at least one externalRef of kind code. It is never a grade you write into a field, and no human click can raise it. Read it against the Realization Probe (its five signals + three actions). Two things your sync controls:

1. the feature's own evidence — reporting it as_built with the externalRefs (kind code) that carry it. This, and only this, is what makes it Built;
2. its bindings — the realized_by / touches edges to the components/entities it uses. These describe the shape of the work; they never decide Built on their own.