# NysaQuest V6 Comprehensive Development Status

**Audit date:** 2026-07-30  
**Audience:** Project manager and future prompt/goal authors  
**Audited deployment:** `C:\nq-lucee\tomcat\webapps\ROOT\_v6`  
**Intended public base:** `http://nysa.quest/_v6/app`  
**Loopback verification base:** `http://127.0.0.1/_v6/app`  
**Report type:** Read-only repository, documentation, configuration, test, and live-route audit

---

## 1. Executive status

V6 is no longer merely a read-only reconstruction. It now contains a narrow production-usable participation product and several production-usable organizer workflows:

1. A governed House operator can Act As an authorized House.
2. The operator can use Event Maker to create, edit, preview, publish, unpublish, archive, and hand Events into the Event Operations lifecycle.
3. The operator can use Quest Maker or Quest Web Forge to author and publish Avatar-, House-, or Event-issued Quests through the V6-owned Quest writer.
4. The exact CONNECTED booth Quest supports authenticated acceptance, signed QR checkpoint proof, zero-Copper completion, permanent Recognition, Character Home return, and governed organizer Results.
5. Event Operations supports readiness, runbooks, incidents, checkpoint availability, protected results, export, closeout, reopen, and immutable operational history.

This is not yet a generally open participation market. The complete participant mutation loop is intentionally narrow and allowlisted to the CONNECTED Quest. General Quest participation/proof/completion, paid Quest funding, membership enrollment, Sponsor authority, Offerings, movement, Signals, generic Forge/Deck/Inventory mutation, media listening proof, account repair, and permanent native authentication cutover remain disabled, controlled-only, or planning-only.

The most accurate project classification is:

> **A production-usable organizer CMS and Event operations system with one production-usable, zero-Copper QR participation vertical slice; many adjacent domains are read-complete or controlled-proved but remain deliberately production-disabled.**

### Current health verdict

| Area | Current verdict |
|---|---|
| Live public shell and representative routes | Available; representative routes returned HTTP 200 |
| House/Event organizer CMS | Production-usable |
| Entity-scoped Quest authoring | Production-usable |
| Event operational lifecycle | Production-usable |
| General participant Quest mutation | Disabled except the exact CONNECTED lane |
| CONNECTED participant loop | Production-usable narrow exception |
| Controlled mutation foundations | Extensive and generally well evidenced |
| Production gates | All 25 gate configuration files are disabled |
| Official safe-suite inventory | Not green because its locked manifest omits a new safe test |
| Underlying discovered safe suites | 55/57 passed in this audit; two failures are classified below |
| Git status/history | Unavailable: this deployment tree has no `.git` metadata and no Git executable |
| Documentation currency | Strong overall, but several older statements and route notes have been superseded |

---

## 2. How future prompts should interpret status

The repository uses maturity terms that must not be collapsed into a single word such as “done.”

| Status | Meaning |
|---|---|
| **Production-usable / production-complete** | A real product route and writer are enabled within the documented authority and policy boundary. |
| **Narrow production exception** | Production mutation is enabled only for an exact allowlisted subject or workflow, not generally. |
| **Read-complete / read-only** | Production reads and UI are usable, but the domain does not authorize mutation. |
| **Controlled-complete / controlled-proved** | A default-off, loopback/admin/manifest-owned proof exercised the writer and cleaned up. It does not authorize production activation. |
| **Foundation / scaffold** | Contracts, routes, schema, or reads exist, but the product workflow is incomplete or intentionally inert. |
| **Planning canon / draft** | Product rules exist on paper. No schema, API, writer, or activation authority follows from the document alone. |
| **Quarantined / later** | Explicitly excluded from current delivery scope. |

### Source precedence for new goals

Use sources in this order:

1. Latest completion records and the latest entries at the top of `V6_REBUILD_STATUS.md`.
2. `V6_CONTRACT_INDEX.md` and the current domain contract.
3. Installed migrations, current services/APIs, gate configuration, and live behavior.
4. `app/config/routes.json` for route inventory, with caution about stale notes.
5. Reconstruction ledgers and older audits for history only.
6. V4/V5 documents as reference-only wherever they conflict with V6 decisions.

Do not treat older “next blocker” language as current if a later completion record closes it. Examples:

- The old Founding Event blocker for governed Quest association was closed by the CONNECTED Quest and later entity-scoped Quest authoring work.
- Older Acting-As documents saying House delegation is disabled were superseded by governed Acting-As activation.
- The July 23 vertical-slice audit predates Event Maker, Quest Maker, Event Operations, Organizer Results v2, and the completed CONNECTED return loop.

---

## 3. Repository and runtime snapshot

### Repository inventory

| Measure | Count |
|---|---:|
| Total repository files | 1,442, including this report |
| CFML route/template files (`.cfm`) | 471 |
| CFML components (`.cfc`) | 206 |
| Markdown files | 241, including this report |
| PowerShell tests/scripts | 129 |
| PNG assets/evidence | 120 |
| JavaScript files | 50 |
| JSON files | 49 |
| SVG files | 52 |
| SQL files | 35 |
| API endpoints under `app/api` | 212 |
| Service components under `app/components/services` | 205 |
| Route partials | 93 |
| Manifest routes | 104 |
| Top-level safe-pattern tests | 57 |
| Explicit mutation proof scripts | 32 |
| Numbered migrations | 32 |
| Proposed migration drafts | 2 |

### Route inventory

| Dimension | Count |
|---|---:|
| Total routes | 104 |
| Non-Laboratory product/operations routes | 60 |
| Laboratory routes | 44 |
| Public routes | 25 |
| Member routes | 24 |
| Admin routes | 55 |
| Alpha `yes` | 19 |
| Alpha `maybe` | 21 |
| Alpha `no` | 64 |

Manifest maturity counts:

| Manifest status | Count |
|---|---:|
| `approved` | 33 |
| `documentation` | 27 |
| `lab` | 18 |
| `read_only` | 7 |
| `production_usable` | 5 |
| `scaffold` | 4 |
| `later` | 3 |
| `read_foundation` | 2 |
| `admin_fixture` | 1 |
| `quarantined` | 1 |
| `controlled_complete` | 1 |
| `disabled_foundation` | 1 |
| `compatibility` | 1 |

### Current gate posture

There are 25 `*gate*.json` files in `app/config`.

- Enabled: **0**
- Disabled: **25**

These cover controlled or migration lanes for Character Home, Deck/Inventory, Entity context, Event Maker proof, Forge, Offerings, pilot permits, Quest authoring/completion/Recognition, Signals, and Spatial Movement. Their disabled state is expected. Production-enabled domain paths use their own exact policies and do not depend on leaving proof gates open.

### Live route spot check from this audit

| Route/API | Result |
|---|---:|
| `index.cfm` | HTTP 200 |
| `events.cfm` | HTTP 200 |
| `quests.cfm` | HTTP 200 |
| `map.cfm` | HTTP 200 |
| `radio.cfm` | HTTP 200 |
| `api/media/station.cfm?station=realm-radio&limit=2` | HTTP 200 |

---

## 4. Architecture and ownership boundaries

### Runtime stack

- Lucee CFML application hosted under Tomcat.
- Shared V6 shell with one route host, one shared navigation system, one Inspector, one overlay host, and one shell-owned media player.
- Server-rendered CFML routes with JavaScript enhancement.
- Domain services are organized under `app/components/services`.
- API endpoints are organized under `app/api` and currently span 41 endpoint families.
- Local Leaflet 1.9.4 supports the interactive symbolic map.
- Shilku map assets are locally owned SVG/GeoJSON/runtime artifacts.
- PowerShell is the primary safe and controlled proof harness; a small number of Node/headless-browser tests provide browser evidence.

### Datasource boundary

- The application-local datasource alias is `nysacore`.
- In V6 it resolves to physical database `nysacore_v6`.
- The V6 runtime user is `nysa_v6_app`.
- V4/V5 continue to use physical `nysacore`.
- V6 was created from a filtered point-in-time clone with retained product/reference data.
- V6 Console proof demonstrated a write in the clone without writing the source database.
- V4/V5 are active external siblings; old frozen file-count baselines are historical evidence, not current acceptance gates.

### Identity and authority doctrine

- Account owns authentication, custody, and administrative identity.
- Avatar is the active in-world participant identity.
- Acting-As changes the governed subject/context; it does not replace the Account/Avatar actor.
- Acting-As alone never grants authority.
- Card ownership, visibility, public access, collection, and admin status do not automatically grant domain capabilities.
- House/Event operations revalidate durable relationship, capability, lifecycle, and subject authority at action time.
- Character Home remains Avatar-owned even when an Entity context is selected.

### Mutation doctrine

Production mutation is domain-owned and narrow. Controlled proof lanes are:

- default off;
- loopback/admin or exact participant scoped;
- manifest-owned;
- idempotent;
- expected to prove failure/rollback behavior;
- required to clean exact fixtures;
- required to return gates to disabled.

Controlled proof success is evidence of readiness, not production authorization.

---

## 5. Product lanes and feature status

### 5.1 Shared shell, navigation, Inspector, and admin tools

**Status:** Production-usable shared platform.

Implemented:

- One shared V6 shell across route families.
- Shared navigation and bottom rail.
- One shared Card Inspector.
- Shared overlays and route-content ownership.
- Shell-level persistent media player with at most one active transport.
- Login/logout authority change clears private media state.
- Admin Tools button controls a collapsible canonical tools rail.
- Tools rail reserves top layout space only while open.
- Extra admin bottom-rail buttons default off.
- Responsive shell and cache-busted CSS/JavaScript.

Latest July 30 verification:

- Admin shell tools smoke: **7/7 passed**.
- Shell media player smoke: **30/30 passed**.

Outstanding:

- The new admin-shell test is not registered in the exact safe-suite inventory.
- July 30 shell changes are newer than the latest main status ledger and should receive a short completion/status entry.

### 5.2 Authentication, Account/Avatar resolution, and native cutover

**Status:** Production authentication remains inherited; V6-native composition is implemented and controlled-proved.

Implemented:

- V6-native SELECT-only authentication context and schema-readiness services.
- Shadow parity for real guest/member/admin and active Avatar resolution.
- Fail-closed missing/stale Avatar handling.
- Active runtime domain consumers no longer construct V4 authentication directly.
- Former 47 direct V4 references reduced to four intentional credential/current-context/onboarding bridges inside two canonical owners.
- Controlled native cutover proved route gates, Wallet, Quest, map, movement readiness, Admin Movement, Console, Acting-As, logout, failure closure, and concurrent sessions.

Still inherited:

- Credential/password verification.
- Login-time compatibility behavior.
- Festival onboarding.
- Production authority mode is restored to `inherited`.

Known blockers:

- The native-cutover completion record reported 20 of 81 retained active Accounts without resolvable active Avatars at that time.
- Permanent cutover requires a missing-Avatar disposition, inherited-login repair decision, rollout, monitoring thresholds, rollback, and session migration.

### 5.3 Account–Avatar repair

**Status:** Read-complete; writer controlled-proved; ordinary production repair disabled.

Implemented:

- Canonical preference field: `accounts.primary_avatar_card_id`.
- SQL `NULL` is the only writer-eligible blank state.
- `v3_avatar_card_id` remains compatibility state and is not co-authoritative.
- SELECT-only redacted Admin queue and classifier.
- Controlled CAS proof for duplicate/conflict/stale/reversal behavior.
- Retained Cohort 1 completed for Account 114.

Current documented queue:

- 32 `preferred_avatar_blank`.
- 32 automatically eligible.
- 0 manual-review cases.

Outstanding:

- No ordinary production Repair/Backfill button or bulk writer.
- Further retained cohorts require explicit authorization.
- Reconcile Account counts across older completion documents before permanent auth planning; retained-data snapshots differ by audit date.

### 5.4 Acting-As and Entity operating context

**Status:** Governed Acting-As is production-usable; cross-domain Entity context is controlled-complete.

Implemented:

- Shared shell lists only subjects the active Avatar may operate.
- Exact governed House selection.
- Session persistence across ordinary routes.
- Reset to Avatar-self.
- Clear on logout.
- Independent action-time authority revalidation.
- Controlled proof across 16 governed Entity types.
- Entity-context Wallet, pending transfer, transfer decisions, Ledger evidence, Home context, and audit attribution.

Important boundary:

- Account/Avatar remains the actor.
- Selected Entity is the subject/context.
- Context never manufactures privileges.

### 5.5 Houses and governed Entity workbench

**Status:** One governed House is production-usable; public Houses remains a read-oriented hub; general House creation is disabled.

Implemented:

- Canonical governed House: The Fairies Pyjamas.
- Normalized slug `the-fairies-pyjamas`.
- Exact durable operator relationship.
- House browse and shared Inspector.
- Governed read and member-routable Entity Workbench.
- Bounded House profile editing.
- House capabilities include durable Event creation for authorized operators.
- Required canonical Entity Wallet projection.

Still disabled:

- General authenticated House creation returns HTTP 501.
- Generic House delegation and broad creation policy.
- Quest Sponsor/public Market authority through House status alone.

Current live evidence:

- The House currently governs two Events:
  - `CONNECTED — A Mile High Open-Air Experience` (active, members-visible).
  - `Fairy parade` (draft, members-visible).

This live count makes the old “exactly one governed Event” safe assertion stale.

### 5.6 Event Maker, publication, and Event Operations

**Status:** Production-complete within House authority.

Event Maker supports:

- Acting-As-authorized House context.
- Create.
- Edit profile and schedule.
- Link existing Venue/Place context.
- Preview.
- Publish.
- Unpublish.
- Republish.
- Archive.
- Handoff into the separate Event operational lifecycle.
- Atomic Event/Card/governance/Forge placement/authoring/lifecycle composition.
- One canonical zero-balance Event identity Wallet.
- Versioned authoring state, idempotent actions, and append-only history.

Event Operations supports:

- Lifecycle/window state.
- Readiness derivation.
- Generated and custom runbooks.
- Incident creation, assignment, resolution, reopen, and duplicate linkage.
- Checkpoint availability controls.
- Scan gating against checkpoint operational state.
- Protected live aggregate Results.
- Safe CSV/JSON export.
- Closeout snapshots and receipts.
- Reopen and versioned re-close.
- Operational Console lane.

House Event Operations UI supports:

- Canonical Event timing.
- Checkpoint expiry and health.
- Quest/Results readiness.
- Remaining capacity.
- Printable local checkpoint QR.
- Bounded event-day runbook.

Explicit non-scope:

- Ticketing.
- Admission payment.
- Passes.
- Reservations.
- Registration.
- Checkout.

### 5.7 Quest authoring

**Status:** Entity-scoped authoring is production-complete; participation boundaries remain separate.

Production surfaces:

- `quest-maker.cfm`: ordinary entity-scoped single-Quest operations.
- `quest-web-forge.cfm`: entity-scoped multi-Quest composition.
- `quest-admin.cfm`: admin-only global review, correction, override, recovery, and diagnostics.
- `quest-studio.cfm`: member draft/review-oriented surface.

Implemented:

- Server-resolved eligible Avatar/House/Event issuer.
- Acting-As-aware default issuer.
- Bounded issuer override.
- Separate beneficiary and Event context.
- V6-owned authoring state, actions, history, publication, Web versioning, replay, and compensation.
- Shared single-Quest writer.
- Migrations 031 and 032.
- Task editor, publication flow, QR tooling, Card/Forge behavior, validation, staging, export, and Web composition.
- Atomic failure and compensation proof.

Known limitations:

- Quest funding remains blocked pending Wallet/Ledger-owned payer approval, escrow, refund, and cancellation contracts.
- Unsupported task types remain publish-blocked.
- Quest Studio is not a second production maker.
- General issuer transfer/reassignment has no ordinary workflow.
- Authoring completion does not activate general participation, proof, completion, reward, Recognition, or Event checkpoint behavior.

### 5.8 CONNECTED booth Quest participation loop

**Status:** Narrow production-usable exception.

Canonical Event:

- `CONNECTED — A Mile High Open-Air Experience`
- Event/Card ID: `B844D0A1-9D49-42F6-889728D5BFD8306F`
- Governing House: The Fairies Pyjamas
- Schedule: August 8, 2026, 2:00–10:00 p.m. America/Denver
- Location: Courtyard by Marriott Denver Downtown West, sixth-floor Skydeck

Canonical Quest:

- `Find The Fairies Pyjamas at CONNECTED`
- Quest/Card ID: `6A120A96-B92B-4212-88667DE49301E7F0`
- Zero Copper.
- One required event-time booth QR step.
- Permanent Recognition: `Fairies Pyjamas Booth Connection`.

Production-enabled for this lane:

- Authenticated acceptance.
- Auto-accept through the signed QR route when needed.
- Canonical QR checkpoint proof.
- Zero-Copper completion.
- One idempotent permanent Recognition receipt.
- Return to Character Home.
- Event Workbench Quest/QR/Results visibility.

Still disabled outside this exact lane:

- General Quest acceptance.
- Arbitrary checkpoint proof.
- General completion.
- Repeat runs.
- Other task systems.
- Coin/Wallet/escrow/Ledger reward movement.
- Unlocks.
- Signals.
- Notifications.
- Offerings.
- Inventory/Deck grants.
- Presence/movement.
- General Event/House authority expansion.

### 5.9 Recognition and Organizer Results

**Status:** Recognition storage/read foundations exist; CONNECTED issuance is production-usable; general issuance remains disabled. Organizer Results is production-usable for governed Event/House contexts.

Implemented:

- Durable Recognition receipt storage.
- Quest Recognition action/outbox schema.
- Controlled completion-to-Recognition integration proof.
- Exact CONNECTED completion-to-Recognition production lane.
- Character Home receipt read.
- Organizer Results v2 with:
  - Quest count.
  - Capacity.
  - Accepted/active/ready/completed separation.
  - Checkpoint readiness and health.
  - Manual review counts.
  - Safe Avatar Card participant identity.
  - Recognition status separate from optional Coin status.
  - Protected House/Event governance.

Outstanding:

- General Recognition issuance is disabled.
- Recognition repair/retry operations remain separate.
- Public Recognition visibility and Quest Market policy are planning canon, not a fully activated product.

### 5.10 Character Home, Console, and Adventure Journal

**Status:** Read-complete; CONNECTED participation return is complete.

Character Home:

- Canonical route is `index.cfm`.
- Combines active Avatar identity, Quest progress, Event context, issuing House, Recognition, optional Coin result, Wallet/Signal/authority reads, and one deterministic primary next action.
- Supports available, accepted, checkpoint-open, ready, completed, Recognition, degraded, and privacy-aware states.
- Receives client-only shell media context without creating a second transport.
- Performs no Home mutation.

Avatar Console:

- Preserved separately at `console.cfm`.
- Member-facing observability and Needs Attention surface.

Adventure Journal:

- Read-only chronology from Quest, reward, Wallet/Ledger, and Offering records.

Outstanding:

- Character Home is still classified `read_only` in the route manifest even though it participates in a production-usable return loop through linked domain actions.
- General Quest next actions remain constrained by disabled participation boundaries.

### 5.11 Cards, Compendium, Forge, Decks, and Inventory

**Status:** Strong read foundation; several controlled-complete mutation lanes; generic production mutation mostly disabled.

Cards/Compendium:

- Shared Card Registry, Card frame, Inspector, and Card Spread.
- Public Compendium and filtered browsers.
- Relationship overlays.
- Curated card art.
- Card-backed Entity/Event/Place/Media presentation.

Forge:

- Generic governed Forge lifecycle is controlled-complete and production-disabled.
- Event Maker has one bounded production composition path that delegates House Forge Deck placement.
- General Card creation/editing, Quick Forge, drag/drop, and arbitrary Deck placement are disabled.

Decks:

- Read surfaces are available.
- Controlled ordinary Deck lifecycle and Forge Deck place/remove/reconcile proofs exist.
- Public collect/add remains disabled.

Inventory:

- Read-only Item Instance custody and provenance.
- Grant/transfer/equip/unequip/consume/revoke are contracted and hard-off.

Activation blockers:

- Delegated curation policy breadth.
- Production grant issuance/revocation.
- Inventory composition.
- Reconciliation monitoring and support ownership.
- Production idempotency retention.
- Rollout and rollback.

### 5.12 Wallet, Ledger, transfers, coupons, and Aquifer

**Status:** Existing Wallet/transfer surfaces and V6 read/contract layers are present; Entity context is controlled-proved; Aquifer remains blocked pending explicit mapping.

Implemented:

- Coin Purse.
- Transfer contract flow.
- Coupon verification/redemption surface.
- Canonical Wallet and Ledger contracts.
- Exact Entity Wallet types and required Wallet migrations.
- Entity-context Wallet/transfer/Ledger proof.
- Ledger-derived read models.
- Economy policy and invariant diagnostics.
- Read-only Economy/Aquifer admin workbench.

Aquifer:

- Documentary decision selected Wallet `0481E4A8-FAF5-41D0-8F7B42595E020FB2`, `account:0 / dragon_wallet`, as the supported canonical backing.
- The competing `system:system_hoard / system_wallet` row is an unused compatibility seed.
- Runtime still returns `blocked / aquifer_mapping_ambiguous` because both rows remain active and no native mapping record exists.
- Ten retained Wallet/Ledger differences remain classified but unrepaired.
- Aggregate retained discrepancy is documented as -68 Copper.

Recommended bounded Aquifer next step:

- Contract and controlled proof for one explicit native mapping record.
- No balance movement or discrepancy repair in the same goal.

### 5.13 Offerings, Bazaar, and Vendor Participation

**Status:** Controlled-complete and production-disabled.

Implemented:

- Read-only Bazaar.
- Offering detail and display/QR surfaces.
- Offering management/readiness/schema foundations.
- No-cost claim and fulfillment controlled proof.
- Fixed paid claim/Ledger/fulfillment controlled proof.
- Support controlled proof.
- Tip controlled proof.
- Idempotency, bounds, source typing, Ledger truth, failure state, and cleanup controls.
- Vendor Participation read model with mode-separated totals and Ledger-derived accounting.

All four initial modes are controlled-proven:

- `no_cost_claim`
- `fixed_claim`
- `support`
- `tip`

Explicitly deferred:

- Production Offering activation.
- Production repair.
- Refunds and reversals.
- Paid-claim cancellation.
- Reusable vendor/booth claim QR.
- Ticket/reservation/catalog/checkout.
- Recurring payments.
- Vendor cashout/Harvest.
- Taxes/external money.
- Notifications/Signals.
- Quest/Recognition integration.
- Inventory/Deck grants.

### 5.14 Signals, Chamber, proximity, and Living Realm

**Status:** Read-complete/controlled-complete; production mutation disabled.

Implemented:

- Passive proximity echoes.
- Active broadcast reads.
- Signal-memory Journal.
- Signal Board read surface.
- Card-target and Deck-target active broadcast models.
- Capacity formula from configured base plus explicit grants.
- Broadcaster-grouped Encounter/Nearby consumption.
- Chamber consumption of current Signals.
- Shared House/Event/Place Chamber read runtime.
- Media projection into Signal and Chamber reads.
- Signal activation/deactivation and capacity controlled proofs.

Outstanding:

- Production activation/deactivation.
- Production capacity grants.
- Product progression thresholds.
- Forge Deck broadcasting.
- Chamber mutation.
- Encounter-to-Compendium mutation.

### 5.15 Interactive map, Shilku, Presence, and movement

**Status:** Map/read layer production-usable; movement controlled-complete and production-disabled.

Map and cartography:

- Locally vendored Leaflet.
- Lazy-loaded only on the map.
- Bounded 0..100 symbolic world.
- Server clustering.
- Projection adapter.
- Shared Inspector/list lifecycle.
- 5,000-point non-database benchmark.
- Local pure-vector Shilku surface.
- Living Realm read layers.
- Guest and member visibility shaping.
- Server-identified Current Avatar with no client fallback.

Movement foundation:

- Canonical symbolic `card_presence` coordinate storage.
- Exact Avatar-self or governed Entity operator policy.
- Versioned state/action/history schema.
- Controlled place and reposition.
- Controlled operator correction and restore.
- Replay, conflict, stale, rollback, cooldown, and cleanup proofs.
- UI preview, confirmation, keyboard adjustment, touch behavior, and reduced-motion handling.

Still disabled:

- Production participant movement.
- Production operator recovery.
- Participant Presence editing controls.
- Routes/pathing.
- Movement intent.
- Journey/follow.
- Caravan movement.
- Heartbeat.
- Scheduler/wandering/autopilot.
- GPS/browser geolocation.
- Alternate regions and region editing.
- Refresh/polling rollout.

Production activation still requires:

- Explicit rollout decision.
- Rate/abuse controls.
- Production observability and rollback operations.
- Interaction/accessibility approval.
- Separate production vertical-slice evidence.

### 5.16 Media Cards, Realm Radio, and shell player

**Status:** Read/playback experience production-usable; server-authoritative listening proof controlled-complete and production-disabled.

Implemented:

- Canonical Media Card/source resolver.
- Visibility and provider trust policy.
- Public Realm Radio.
- Shared Inspector playback delegation.
- One persistent shell player.
- At most one active transport.
- SoundCloud controlled sandbox adapter.
- Bounded/redacted station reads.
- Media Deck projection.
- Read-only Signal and Chamber media integration.
- Responsive desktop/tablet/phone behavior.
- Local preference persistence only.

Production-disabled:

- `listen_song` proof.
- Media uploads.
- Playlists/queues.
- Station editing.
- Durable playback history.
- Direct playback-to-Quest/Recognition/economy mutation.

Future `listen_song` prerequisites:

- Browser-to-server progress candidate transport.
- Abuse/rate/tab/background/clock-skew policy.
- Durable concurrent idempotency and recovery.
- Source revocation/private-authority handling during play.
- Cohort, kill switch, monitoring, and rollback.
- Live participant proof that changes only the Quest step.

### 5.17 Laboratory, documentation, and admin observability

**Status:** Large admin-only project intelligence system; functional but currently above one test timeout budget.

The 44 Laboratory routes include:

- Site and route atlas.
- Source/evidence atlas and allowlisted readers.
- Runtime component atlas.
- Data/persistence atlas.
- Endpoint/action atlas.
- Service/capability atlas.
- Client interaction atlas.
- Gate activation atlas.
- Authority/capability atlas.
- State/lifecycle atlas.
- Observability/audit atlas.
- Configuration/policy atlas.
- Decision impact atlas.
- Experiment/editability atlas.
- Functional trace atlas.
- Unified project index.
- Knowledge graph.
- Economics, membership, value movement, authority, media, QR, custody, safety, and system-boundary explorers.
- Revision-tracked decisions, model variables, economic scenarios, and documentation coverage.

Documentation inventory under `docs`:

- 221 top-level Markdown documents, including this report.
- 77 contract-named documents.
- 57 completion/result documents.
- 14 audit documents.
- 18 plan/handoff/backlog/next-goal documents.

Current issue:

- `lab-health.cfm` returned HTTP 200 with `Integrity checks passing`, but took approximately 35 seconds in this audit.
- `v6-laboratory-runtime-smoke.ps1` has a 30-second per-request timeout and therefore fails before completing its full assertion set.

### 5.18 Membership, Quest Market, Sponsor authority, and safety

**Status:** Planning canon/draft only; no implementation authority.

Planning canon exists for:

- Paid, invitation-based membership.
- Account-owned paid standing with Avatar participation projection.
- Entity operating standing.
- Entry Sponsorship.
- Quest Sponsor authority.
- Quest Market.
- Public Recognition policy.
- Sponsor accountability.
- Trust, safety, community mediation, restrictions, and escalation.

Current public availability:

- Selected public content may be viewed.
- Membership enrollment is not open.
- Sponsored passes are not open.
- Pricing and billing are not open.
- Quest Sponsor authority is not active.

Highest-leverage unresolved membership decisions:

1. One active Avatar per paid Account initially versus multi-Avatar entitlement.
2. Entity-specific standing sources versus bundled Account plans.
3. Restriction as an overlay versus lifecycle state.
4. Initial creator cohort.
5. Entry Sponsor Account-only versus optional Entity co-context.
6. Payment lapse/grace timing.
7. Succession and obligation-hold operations.
8. Override approvers, duration, notice, and review.
9. Whether Event eligibility derives from governing-House standing.
10. When CONNECTED participation begins enforcing paid standing.

No future goal should implement membership storage, billing, Sponsor writers, passes, invitations, or route enforcement until these branches are approved.

---

## 6. Schema and migration status

### Numbered migrations

| Range | Ownership |
|---|---|
| 001–010 | Inherited/system events, transfer, Quest reward, Deck, Quest Web Forge, completion rules, escrow, coupons, and curated art foundations |
| 011 | V6 Recognition storage |
| 012 | V6 Quest Recognition action/outbox |
| 013 | V6 Offering/Vendor |
| 014 | Governed Forge actions |
| 015 | Deck/Inventory foundation |
| 016 | Signal Deck capacity |
| 017 | Spatial movement foundation |
| 018 | Authority grants |
| 019 | Spatial production controls |
| 020–021 | Compendium/House/Jucifer cleanup |
| 022–025 | Laboratory variables, economic scenarios, actor identity, and decision register |
| 026 | Riverdale admin demo fixture ownership |
| 027–028 | Required and creator Entity Wallets |
| 029 | Event Operations |
| 030 | Event authoring/publication |
| 031 | Entity-scoped Quest authoring |
| 032 | Quest Web authoring context |

### Proposed only

- `V6_QUEST_CHECKPOINT_ACTION_SCHEMA_DRAFT.sql`
- `V6_RECOGNITION_SCHEMA_DRAFT.sql`

Proposed files are not installed authority. New goals must verify actual schema status through the existing schema/read services rather than inferring installation from file presence.

---

## 7. Current route highlights

### Alpha `yes`

| Route | Title | Manifest status | Access |
|---|---|---|---|
| `index.cfm` | Character Home | `read_only` | Public shell / member content |
| `compendium.cfm` | Compendium | `approved` | Public |
| `people.cfm` | People | `approved` | Public |
| `events.cfm` | Events | `production_usable` | Public plus governed drafts |
| `deck.cfm` | Decks / Keepsakes | `approved` | Member |
| `journal.cfm` | Signals | `read_only` | Member |
| `console.cfm` | Avatar Console | `approved` | Member |
| `activity.cfm` | Adventure Journal | `approved` | Member |
| `wallet.cfm` | Coin Purse | `approved` | Member |
| `transfer.cfm` | Transfer | `approved` | Member |
| `coupon.cfm` | Coupon Verify | `approved` | Member |
| `quest-maker.cfm` | Quest Maker | `production_usable` | Member |
| `entity-workbench.cfm` | Entity Workbench | `production_usable` | Member |
| `event-maker.cfm` | Event Maker | `production_usable` | Member |
| `house-event-operations.cfm` | House Event Operations | `production_usable` | Member |
| `confirm-email.cfm` | Confirm Email | `approved` | Public |
| `qr-display.cfm` | QR Display | `approved` | Admin |
| `quest-qr-sheet.cfm` | Quest QR Sheet | `approved` | Admin |
| `q.cfm` | QR Direct Entry | `approved` | Public entry |

### High-signal `maybe`, foundation, disabled, or later routes

| Route | Status | Current meaning |
|---|---|---|
| `houses.cfm` | `scaffold` | Public read hub; one governed House is production-usable through authority/workbench paths |
| `societies.cfm` | `scaffold` | Read-only House/Guild/Circle vocabulary |
| `bazaar.cfm` | `scaffold` | Read-only Offering browser |
| `offerings.cfm` | `compatibility` | Alias to Bazaar |
| `offering.cfm` | `approved` | Read/detail surface; production Offering mutation remains disabled |
| `offering-display.cfm` | `approved` | Performance/tip QR display; mutation remains disabled |
| `map.cfm` | `read_only` | Production symbolic map; movement disabled |
| `chamber.cfm` | `read_only` | Shared Entity interior reads |
| `broadcast-studio.cfm` | `read_only` | Signal Board reads; mutation disabled |
| `quests.cfm` | `approved` | Public/read Quest observation; note is stale about the exact CONNECTED exception |
| `quest-studio.cfm` | `approved` | Member draft/review, not Entity Quest Maker |
| `inventory.cfm` | `read_foundation` | Custody/provenance reads; all writers hard-off |
| `movement.cfm` | `disabled_foundation` | Symbolic movement foundation; no production movement controls |
| `forge.cfm` | `controlled_complete` | Generic governed Forge controlled-proved; production disabled |
| `vendor-participation.cfm` | `scaffold` | House-scoped Offering results/read workbench |
| `video-library.cfm` | `later` | Out of current alpha |
| `watch-video.cfm` | `later` | Out of current alpha |
| `caravans.cfm` | `later` | Future group/crew workflow |
| `quick-forge.cfm` | `quarantined` | Admin/dev future tooling only |

---

## 8. Verification status from this audit

### Official exact-inventory result

Command:

```powershell
powershell.exe -NoProfile -ExecutionPolicy Bypass `
  -File tests\v6-safe-suite-inventory.ps1 `
  -BaseUrl http://127.0.0.1/_v6/app
```

Result:

```text
FAIL — Safe inventory mismatch.
missing=
unexpected=v6-admin-shell-tools-smoke.ps1
```

Interpretation:

- The official aggregator does not currently execute its suite because test discovery no longer matches the locked required list.
- This is a registry/manifest defect.
- The newly discovered test is itself safe and passed 7/7.
- Until the inventory is deliberately updated and rerun, the project must not claim a current official exact safe-inventory pass.

### Manual underlying safe-pattern run

The 57 discovered `tests/v6-*-smoke.ps1` files were executed individually with the same loopback base.

| Result | Count |
|---|---:|
| Passed | 55 |
| Failed | 2 |
| Total | 57 |
| Runtime | Approximately 196 seconds |

#### Failure 1: House/Event exact-count assertion

Suite:

```text
v6-house-entity-read-smoke.ps1
```

Result:

- 21 passed.
- 1 failed: `House read exposes exactly the founding governed Event`.

Classification:

- The test expects `governedEventCount == 1`.
- Live canonical data now returns two governed Events for The Fairies Pyjamas:
  - CONNECTED.
  - Fairy parade.
- The CONNECTED Event is still present and correctly governed.
- This is most likely a stale cardinality assumption after the production Event Maker created or retained another valid governed draft, not evidence that House/Event governance is broken.
- The assertion should prove inclusion and authorization shaping rather than a permanent global count of one, unless the product explicitly requires only one Event.

#### Failure 2: Laboratory timeout

Suite:

```text
v6-laboratory-runtime-smoke.ps1
```

Result:

- Guest/member/admin gates and the initial admin pages passed.
- The run timed out when it reached the Laboratory health audit.

Isolated verification:

```text
lab-health.cfm
HTTP 200
76,103 bytes
~35.01 seconds
Contains "Integrity checks passing"
```

Classification:

- The page is functional.
- The test has a 30-second request timeout.
- Current generation/inspection cost exceeds that budget by about five seconds.
- This is a real performance/harness-budget issue and should be addressed rather than hidden by simply declaring the suite green.

### Focused July 30 checks

| Suite | Result |
|---|---:|
| `v6-admin-shell-tools-smoke.ps1` | 7/7 |
| `v6-shell-media-player-smoke.ps1` | 30/30 |

No external media was loaded by the media smoke.

### Prior accepted evidence retained in the repository

Recent completion records report:

- Entity-scoped Quest authoring focused: 12/12.
- Quest authoring controlled mutation/cleanup: 41/41.
- Quest authoring browser/accessibility: 37/37.
- Event Maker safe: 30/30.
- Event Maker production: 36/36.
- Event Maker browser: 114/114.
- Event Operations production: 38/38.
- Event Operations browser: 53/53.
- House Event Operations: 34/34.
- CONNECTED end-to-end: 19/19.
- Character Home CONNECTED return controlled: 25/25.
- Acting-As safe: 23/23.
- Native auth read foundation: 47/47.
- Native controlled cutover: 34/34.
- Spatial controlled and browser proof sets: accepted in their domain completion records.
- Offering controlled modes: accepted in their domain completion record.
- Media controlled listen: 20/20.

These remain historical accepted evidence. They do not override the two current safe-suite drifts described above.

---

## 9. Documentation and configuration drift

The documentation system is unusually comprehensive, but future prompts should account for these specific drifts:

1. **Safe inventory is stale.** It omits the July 30 Admin shell test.
2. **House test cardinality is stale.** It assumes the founding House can govern exactly one Event.
3. **Laboratory timeout is stale or performance has regressed.** Health generation now takes about 35 seconds against a 30-second test budget.
4. **`routes.json` contains superseded notes.**
   - `quests.cfm` says all Quest actions remain disabled, but the exact CONNECTED action lane is enabled and Quest authoring is production-usable elsewhere.
   - `houses.cfm` remains `scaffold` even though the governed House/workbench path is production-usable.
   - `quest-web-forge.cfm` is marked `approved`/alpha `no` despite the authoring completion record describing it as production-complete for eligible entity operators.
5. **`V6_REBUILD_STATUS.md` is cumulative rather than fully normalized.**
   - New completion statements at the top supersede older “next blocker” paragraphs lower in the same document.
   - The isolated “Status date: 2026-07-11” applies to the nearby spatial entry, not the whole file.
6. **July 30 shell changes lack a main status/ledger entry.**
7. **Deployment tree has no Git metadata.**
   - No branch, commit, remote, dirty-worktree, or change-history claim can be verified from this path.
8. **Configured workspace drive differs from the live host path.**
   - Session context named `D:\nq-lucee\...`.
   - The available audited deployment is `C:\nq-lucee\...`.
   - Older docs also contain D-bound language. Prompts should avoid hard-coding a drive unless the execution environment is first checked.

---

## 10. Open decisions, blockers, and deferred scope

### 10.1 Immediate engineering hygiene

1. Register `v6-admin-shell-tools-smoke.ps1` in the exact safe inventory.
2. Decide whether House/Event tests should expect “contains canonical Event” or an exact manifest-owned Event set.
3. Diagnose and reduce `lab-health.cfm` generation time or explicitly redesign the test/runtime budget with evidence.
4. Rerun the official exact inventory only after the registry and failing assumptions are reconciled.
5. Update route manifest notes/statuses for Quest Web Forge, CONNECTED Quest actions, and governed House/Event behavior.
6. Add July 30 shell/Admin tools work to the rebuild status and reconstruction ledger.

### 10.2 Product activation decisions

These domains are controlled-proved but need separate production decisions:

- Generic Quest participation/proof/completion beyond CONNECTED.
- Quest funding/escrow/refund/cancellation.
- General Recognition issuance/repair.
- Offerings and Vendor Participation.
- Generic Forge/Deck/Inventory writes.
- Signals and capacity changes.
- Spatial movement and operator recovery.
- Media `listen_song`.
- Account–Avatar repair cohorts.
- Permanent V6-native auth.
- Aquifer explicit mapping.

### 10.3 Product policy decisions

- Membership standing and pricing.
- Sponsor authority.
- Entry Sponsorship/pass behavior.
- Quest Market publication/withdrawal/obligations.
- Safety workflows, retention, appeals, mediator requirements, emergency/jurisdiction handling.
- Signal progression thresholds.
- Movement abuse/rate/cooldown/rollout policy.
- Aquifer discrepancy repair policy.

### 10.4 Explicit later scope

- Video Library and Watch Video.
- Caravans.
- Journey/follow/wandering/autopilot.
- Alternate-region and region-editing tools.
- Generic ticketing, reservations, registration, and checkout.
- External money, taxes, recurring payments, and cashout.

---

## 11. Recommended next goal sequence

The next prompts should be small enough to retain the existing evidence discipline. A practical sequence follows.

### Goal 1 — Restore current acceptance truth

**Outcome:** One official exact safe inventory passes against the current route/service/test registry.

Scope:

- Add the Admin shell tools test to the required safe inventory.
- Replace the House “exactly one Event” assumption with an authority- and identity-correct assertion, or document why the second Event is invalid and handle it under a separate data goal.
- Profile `lab-health.cfm`.
- Preserve its integrity coverage while returning within an approved budget.
- Rerun all discovered safe suites.
- Update the relevant status and test documentation.

Do not:

- Delete the `Fairy parade` Event as a test fix.
- Increase a timeout without profiling and recording the reason.
- Enable any controlled gate.
- Run mutation proof suites as part of safe discovery.

Acceptance:

- Required count equals discovered count.
- Official inventory reports all pass.
- Zero V6MUT residue.
- All 25 config gates remain disabled.
- Representative public/member/admin route checks remain green.

### Goal 2 — Normalize project truth sources

**Outcome:** Route manifest, rebuild status, reconstruction ledger, contract index, and safe inventory agree about current production lanes.

Scope:

- Update stale route statuses/notes without changing product authority.
- Add July 30 shell/Admin tools completion entry.
- Mark superseded old blockers explicitly.
- Add a concise current status taxonomy.
- Verify Laboratory route/endpoint/service counts after changes.

Do not:

- Change access gates merely to match desired wording.
- Treat `approved` as production mutation authority.

### Goal 3 — Choose one activation lane

Recommended order:

1. **Aquifer explicit mapping contract and controlled proof** if economy truth is the priority.
2. **Account–Avatar retained Cohort 2** if identity readiness is the priority.
3. **Permanent native-auth decision packet** only after missing-Avatar disposition is approved.
4. **One additional Quest participation type/Quest** if participant product breadth is the priority.
5. **Offering production activation packet** only after repair/refund/abuse/rollout decisions.
6. **Spatial movement production pilot** only after rate/abuse/observability/rollback policy.

Each activation goal must explicitly name:

- Product outcome.
- Exact actors and subjects.
- Exact route/API.
- Canonical data owner.
- Capability decision.
- Idempotency owner.
- Gate/permit boundary.
- Allowed writes.
- Forbidden side effects.
- Failure injection points.
- Cleanup/rollback.
- Observability.
- Responsive/accessibility proof.
- Safe-suite registration.
- Documentation updates.

### Goal 4 — Membership/Sponsor product decision workshop

This is a decision goal, not an implementation goal.

Resolve the ten membership branches listed in section 5.18, then approve or reject the draft contract. Only after approval should a new implementation prompt define a membership-standing read model and controlled storage proof.

---

## 12. Prompt guardrails for the project manager

Every future implementation prompt should include these constraints unless the domain contract explicitly supersedes them:

- Work only in `_v6`.
- Treat V4/V5 as reference-only and do not edit them.
- Verify the actual filesystem drive before using absolute paths.
- Preserve the V6 datasource boundary.
- Do not infer authority from Acting-As, Card ownership, visibility, admin role, or client-supplied IDs.
- Keep Account/Avatar actor identity distinct from governed subject identity.
- Reuse the shared shell, navigation, Inspector, overlays, Card frame, and media player.
- Do not add route-local media transports.
- Keep reads free of hidden writes.
- Do not execute DDL at request time.
- Do not add a production writer to a controlled proof endpoint.
- Keep migration/proof gates default off and exact scoped.
- Use idempotent actions and stable conflict/replay behavior.
- Inject and prove transactional failures for new mutation paths.
- Compare protected state before and after controlled proofs.
- Clean only exact manifest-owned fixtures.
- Leave zero V6MUT residue and every temporary gate disabled.
- Separate schema installation, controlled proof, and production activation into distinct authorization decisions.
- Update the safe-suite inventory when adding a top-level safe test.
- Update route manifest, status ledger, reconstruction ledger, contract index, and completion record when a lane materially changes.
- Do not claim browser acceptance without actual responsive and accessibility evidence.
- Do not claim an official full-suite pass when only focused tests passed.

---

## 13. Risks

| Risk | Severity | Current evidence | Recommended control |
|---|---|---|---|
| Status drift across cumulative documents | High | New completion entries coexist with obsolete blockers | Normalize truth sources in Goal 2 |
| Safe-suite registry drift | High | Official runner stops before executing tests | Fix inventory and rerun |
| Laboratory performance | Medium–High | Health page takes ~35s, above 30s budget | Profile/caching/indexing or justified budget redesign |
| Test data cardinality assumptions | Medium | House test assumes one Event; live product has two | Assert governed identity/visibility, not frozen global count |
| Inherited authentication dependency | High | Production mode remains inherited | Resolve missing Avatar and credential bridge before cutover |
| Broad controlled proof mistaken for production readiness | High | Many domains are controlled-complete | Require explicit activation goal and rollout controls |
| Aquifer ambiguity/accounting discrepancies | High | Runtime blocked; -68 aggregate retained discrepancy | Map first; repair only under separate accounting policy |
| Membership/Sponsor policy not approved | High | Draft contract has no implementation authority | Resolve product branches before schema/workflow work |
| Route manifest status semantics are inconsistent | Medium | `approved`, `read_only`, and production reality do not always align | Define and apply canonical route maturity taxonomy |
| No Git metadata in deployment | Medium | Cannot verify branch/commit/dirty state | Audit from source repository before release/change-history claims |

---

## 14. Evidence index

Start future planning with:

- `docs/V6_REBUILD_STATUS.md`
- `docs/V6_RECONSTRUCTION_LEDGER.md`
- `docs/V6_CONTRACT_INDEX.md`
- `docs/V6_ROUTE_MANIFEST.md`
- `app/config/routes.json`
- `tests/README.md`
- `tests/v6-safe-suite-inventory.ps1`

Current production organizer and participation evidence:

- `docs/V6_ENTITY_SCOPED_QUEST_AUTHORING_CONTEXT_COMPLETION.md`
- `docs/V6_HOUSE_GOVERNED_EVENT_MAKER_COMPLETION.md`
- `docs/V6_HOUSE_EVENT_PRODUCTION_LIFECYCLE_COMPLETION.md`
- `docs/V6_HOUSE_EVENT_OPERATIONS_COMPLETION.md`
- `docs/V6_CONNECTED_BOOTH_QUEST_COMPLETION.md`
- `docs/V6_CHARACTER_HOME_PARTICIPATION_RETURN_COMPLETION.md`
- `docs/V6_ORGANIZER_RESULTS_COMPLETION.md`
- `docs/V6_ACTING_AS_ACTIVATION_COMPLETION.md`
- `docs/V6_ENTITY_OPERATING_CONTEXT_COMPLETION.md`

Controlled/read foundations:

- `docs/V6_NATIVE_AUTH_CONTROLLED_CUTOVER_PROOF_COMPLETION.md`
- `docs/V6_ACCOUNT_AVATAR_PREFERENCE_BACKFILL_CONTROLLED_PROOF_COMPLETION.md`
- `docs/V6_DECK_COMPENDIUM_INVENTORY_LEG_COMPLETION.md`
- `docs/V6_OFFERING_VENDOR_LEG_COMPLETION.md`
- `docs/V6_SIGNAL_DECK_CAPACITY_ENCOUNTER_LEG_COMPLETION.md`
- `docs/V6_SPATIAL_MOVEMENT_COMPOSITE_BROWSER_PROOF_COMPLETION.md`
- `docs/V6_MEDIA_REALM_RADIO_HANDOFF.md`
- `docs/V6_AQUIFER_MAPPING_GOVERNANCE_COMPLETION.md`

Planning canon:

- `docs/V6_PRODUCT_CLOSURE_BACKLOG_2026-07-22.md`
- `docs/V6_MEMBERSHIP_STANDING_AND_QUEST_SPONSOR_AUTHORITY_CONTRACT.md`
- `docs/V6_MEMBERSHIP_STANDING_DECISION_LEDGER.md`
- `docs/V6_MEMBERSHIP_STANDING_IMPLEMENTATION_DEPENDENCIES.md`
- `docs/V6_QUEST_MARKET_CONTRACT_v0.2.md`
- `docs/V6_TRUST_SAFETY_AND_COMMUNITY_ACCOUNTABILITY_CONTRACT_v0.1.md`

---

## 15. Final handoff summary

The project has crossed an important threshold: V6 now owns real organizer workflows and one complete real-world participation loop. The next phase should not be framed as “build the site.” It should be framed as:

1. restore exact acceptance truth;
2. normalize status/documentation;
3. choose one deliberately bounded activation lane;
4. resolve membership/Sponsor product decisions before implementing that economy of authority.

The strongest immediate engineering goal is the acceptance-truth repair described in Goal 1. It is bounded, high leverage, non-destructive, and will give every later prompt a trustworthy green baseline.

The strongest immediate product goal is a decision workshop for membership standing and Quest Sponsor authority. Those decisions constrain auth, House/Event operation, Quest Market discovery, passes, safety, billing, and the transition of the existing CONNECTED lane.

Until those steps are complete, future prompts should preserve the current successful narrow product rather than broadening multiple controlled domains at once.