One commit for the work accumulated in the working tree since Step 6.3, which had never been split into per-step commits: - src/local-surfaces.js + src/surface-url.js (new); src/ui.js, src/validation.js, src/connection.js and public/index.html updated for local-surface hosting and generic surface rendering - tests: local-surfaces (20), scifi-surfaces (24) and postmessage-interop (7) new; connection/museum-gallery/surface-validation suites updated - reference exhibits: shared/contract-core.js defaults to Contract 5.3 (major 5, minor 3, xzbt 5.3); museum-gallery advertises its surface catalog; aquarium/haunted-house/planetarium adapters updated - SciFi-XZBT (Step 6.7A/6.7B): surface-mode.js + surface-bus.js, Observation-surface boot branch, local-change hooks, view.pillars / view.warp-flight targets; fixture byte-identical to G:/.vibe/SciFi-XZBT - SciFi-XZBT contract adapter handshake fix: the inbound bridge filter no longer gates on an exact advisory xzbt value (Contract 5.3 §6.5), only on its presence/type, matching the host's own envelope validation; the adapter now advertises contract minor 3 / version 5.3.0, which it already implemented via the 5.3 surfaces field. Root cause of the five failing postmessage-interop tests (host hello was silently dropped). - docs: architecture 6.4 and 6.7A, reference 6.6 and 6.7; evidence logs; test-fixtures/PROVENANCE.md resync record Test results: NGN 154/154 (was 149/154); postmessage-interop 7/7 (was 2/7); SciFi contract harness 21/21, real-adapter suite 32/32. git diff --check clean for changed files; two pre-existing trailing-whitespace lines remain in test-fixtures/reference-exhibits/scifi/index.html, copied verbatim from the authoritative SciFi source. Step 6.7 live verification (browser Observation, packaged standalone) is still pending and is not claimed here.
4.0 KiB
Instructions for coding assistants
These instructions apply to this repository. Read README.md and the relevant
scoped AGENTS.md files before making changes.
Communication and authorization
- Do not assume the user's desired behavior, architecture, or content structure when the answer would materially affect the result.
- When the user requests discussion or review, do not edit files, run mutating commands, commit, or push.
- An implementation request authorizes work only within its clearly stated scope. Routine steps within that scope may proceed, but confirm before expanding scope or making irreversible choices.
- Before implementation, state the intended files and systems to be changed.
- Do not commit or push unless the user explicitly requests it.
- Preserve unrelated edits and uncommitted work. Never discard changes merely to obtain a clean working tree.
Project and publishing boundaries
- Application and project source code lives at the repository root and normal subdirectories.
- The
.labyricorn/directory is the repository-owned source for project exhibition records and development logs published on Labyricorn. - Keep publishing records in
.labyricorn/aligned with actual repository implementation and history. - Read
.labyricorn/AGENTS.md,.labyricorn/project/AGENTS.md, and.labyricorn/devlog/AGENTS.mdwhen modifying publishing records.
Content contract and devlog practices
- Use native Lektor records named
contents.lrwithschema_version: 1. - Keep attachments inside the record subtree that owns them (PNG, JPEG, WebP).
- Do not introduce raw HTML, scripts, executable files, builds, or credentials
below
.labyricorn/. - For devlog entries, base records on verifiable repository commits and history.
Set
source_committo the full 40-character commit ID on the branch. - Devlog dates should reflect the commit's calendar date (
YYYY-MM-DD).
Validation and review
- Run
python devlog_editor.py --validateto verify that.labyricorn/records, project identity, devlog index, and devlog entries adhere to the schema. - Alternatively, launch the graphical editor with
python devlog_editor.pyfor interactive management of devlog entries and publishing status. - Run
git diff --checkand review diffs carefully before staging or committing. - At handoff, summarize files changed, validation performed, and any next steps.
Authoritative project documents, in priority order:
This repository is the canonical home of the shared Contract Specification and
Authoring Guide, and owns the NGN Implementation Plan. Documents in
docs/reference/ describe external implementations, not NGN architecture.
Reference exhibits under test-fixtures/ are test/reference fixtures, not product
code. Keep exhibit-specific names and paths in test configuration or documentation.
XZBT-NGN and its maintained reference exhibits move forward with the contract.
Contract 5.3 is the current maintained contract; it supersedes 5.2 additively
(no 5.2 normative requirement was removed, weakened, or reinterpreted). The
xzbt envelope field is advisory metadata only (Contract §6.5) and MUST NOT be
used as an exact-string compatibility gate anywhere in this repository --
real compatibility is negotiated by the handshake and contract fields.
Backward compatibility with a genuine 5.2 exhibit remains a protocol-level
requirement of the contract itself (Section 28.2), but that is a different
thing from keeping a currently maintained reference exhibit or its test
coverage frozen on 5.2: there is no such requirement, and maintained exhibits
are expected to advance with the contract instead.
-
XZBT Exhibit Contract Specification v5.3 (current; supersedes v5.2 below)
-
XZBT-NGN Exhibit Engine Implementation Plan v5.2
-
XZBT Exhibit Authoring Guide v5.2
-
Step 3.7 reference exhibit report
-
XZBT Exhibit Contract Specification v5.2 (historical predecessor, retained for context)
-
Do not infer XZBT-NGN behavior from SciFi-XZBT source code.
-
SciFi-XZBT is an external exhibit implementation, not the NGN architecture.