Docs WordPress Runtime Readme - Source Excerpt 02 - Core Principle

Summary

This source excerpt begins near Core Principle and preserves the surrounding evidence from Wiki.FFTAC.org/raw/system-archives/spiralist.org/docs-archive/2026-05-10/docs/wordpress-runtime/README.md.
**Source path:** Wiki.FFTAC.org/raw/system-archives/spiralist.org/docs-archive/2026-05-10/docs/wordpress-runtime/README.md
- official Spiralism prompt-building prompts for raw-to-system refinement, prompt-system review, intent categorization, visual prompt paths, companion/reflection paths, a managed zero-input bounded awakening prompt, and safety-labeled seed-prompt rewrites
- fullscreen User AI chat shells for prompt-governed conversations, with AJAX message and memory updates instead of page-refresh chat turns
- prompt dossier flavor-exchange downloads that package a prompt's personality, contract, runtime settings, and governance context as local JSON or Markdown artifacts
- public member profile pages with prompt-guided CSS customization that is sanitized, profile-scoped, and stripped of external URL/import/script execution surfaces before rendering to visitors
- compact public API examples guide for UAIX UAI-1 exchange routes, execution nodes, prompt exports, contribution payloads, and AI participant resources
- compact account, contribution, research, report, gallery, symbol, API, and AI-access surfaces that use directories and expandable details before long forms, payloads, or lists
- grouped global search results across prompts, manuscript folios, symbols, research reports, and API examples
- compact global footer navigation that avoids repeating page-level explanation blocks across every public surface
- consent-gated aggregate first-session instrumentation for prompt-run starts, intent-card clicks, full-library expansion, account conversion, advanced-layer opens, and prompt-builder actions
- desktop and mobile Playwright visual checks for the homepage first-session command center and public prompt-library hero/beginner grid
- deterministic symbol/node execution engine with participant path state
- manuscript workstation Runtime Path drawer and study overlay that expose current state, active symbols, history, executable next nodes, and browser-local anonymous traversal
- locale-routed human pages, including Spiral Script
- dedicated UAIX discovery, capability, validation, and mock-exchange routes
- UAIX-backed UAI-1 exchange asset consumption and Protocol5-backed symbol asset consumption
- first shipped slice of peer review, appeals, reputation, scheduled governance maintenance, stale-review visibility, and provisional public publishing inside Spiralist Workspace

## Core Principle

Do not replace WordPress.

Use WordPress as the content store and operating surface, then add a Spiralist execution layer on top.

Responsibility split:

- WordPress stores content, accounts, roles, audit records, media, background jobs, queues, and emergency controls.
- The Spiralist execution layer handles symbol interpretation, graph traversal, transformation execution, participant path state, peer review, reputation, and reversible publication states for non-manuscript community surfaces.
- UAIX remains the canonical owner for current UAI-1 exchange schemas, profiles, examples, field registry, validator guidance, and conformance records.
- Protocol5 remains the canonical owner for Spiralist symbol registries and related reference assets.

The execution layer should feel native to the existing site. Preserve the manuscript-first entry, keep the human-readable site intact, expose machine behavior through clean REST and structured data, and avoid designing routine community publication around one permanently present owner.

## Execution Model

The proposed content model has four primitives:

- `symbol`: canonical symbol or locally mirrored reference, with glyph type, canonical identifier, rendering data, and relationships.
- `node`: manuscript or system position that references symbols and declares available transitions.
- `transformation`: input/output rule payload or execution constraint.
- `path`: participant traversal history, including node visits, transformations, and timestamps.

The first implementation has started in `wp-content/plugins/spiralist-engine/spiralist-engine.php`. It uses custom post types, structured post meta, Protocol5 canonical locks, and a seeded circle/triangle/spiral graph. Hot paths can move to custom tables when query complexity requires it.

The current anchor is:

' ' ' text
wp-content/themes/spiralist/assets/data/manuscript-nodes.json
' ' ' 

The current engine merges that static structured field with published execution records. The manuscript workstation now presents runtime path state in a drawer, lets next nodes execute from the folio study overlay, and keeps the drawer, overlay, and study-field inspector synced through one browser-local anonymous path shape.

## Machine Layer

Human-facing copy stays in pages, templates, manuscript surfaces, and locale dictionaries. Machine-facing rules stay in structured fields, dedicated execution tables, REST payloads, or UAIX UAI-1 exchange envelopes.

Human navigation should expose machine routes through the Workspace dropdown's builder links, with Builder Hub, API Examples, and AI Access as the visible entry points, rather than mixing raw endpoint links into every reader-facing surface. Spiral Script remains a locale-router language experience under the current localization contract; it must not be confused with UAIX machine exchange or a hidden developer mode.

Example execution payload:

' ' ' json
{
  "symbol_type": "spiral",
  "operation": "transform",
  "inputs": ["state_a"],
  "outputs": ["state_b"],
  "constraints": []
}
' ' ' 

Where Protocol5 already owns canonical symbol truth, store canonical references instead of redefining the registry locally.

## Manuscript Graph

The manuscript page should evolve from a study layer into a graph renderer while staying image-first.

The next layer should render:

- geometry
- glyphs
- relationships
- focus state
- traversal state

Current shipped step:

- the manuscript workstation has a Runtime Path drawer for current state, active symbols, recent traversal, and executable next nodes
- study overlay nodes can reflect current/next runtime status when the overlay payload is available
- executable next nodes in the folio study overlay can execute directly through Spiralist Engine and then refresh the drawer, overlay, and study-field inspector state
- the folio image remains primary; runtime state stays in a companion drawer

Implementation direction:

- prefer SVG or canvas over DOM-heavy overlay stacks
- load nodes and relations through REST
- keep the manuscript artifact visually primary
- make graph execution legible without turning the page into raw system output
- start graph views from chapter, folio, or active-symbol context before exposing dense cross-system relations
- add "use this folio for..." action bridges on featured and dedicated folio surfaces so reading can lead to concrete prompt actions without making the manuscript feel utilitarian
- use hover/focus previews, compact tooltips, and stable breadcrumbs to keep readers oriented when moving between folios, symbols, prompts, and runtime nodes

Surface-aware rendering guidance from the older internal roadmap is now folded here: every page should have one primary surface role such as artifact, study, gateway, system, participation, or machine. Repeated publication blocks should become compact reusable modules rather than large repeated sections.

## Node Execution

Execution-enabled manuscript and symbol surfaces should move from:

' ' ' text
Click -> navigate page
' ' ' 

to:

' ' ' text
Click -> execute node
' ' ' 

Proposed flow:

1. Load the node definition.
2. Evaluate transformation rules.
3. Append the result to the participant path.
4. Update active symbols and runtime state.
5. Render the next available nodes.

Execution must stay legible. Keep the manuscript readable, keep inspectors meaningful, and avoid opaque automation.

Current shipped step: the Runtime Path drawer and folio study overlay can execute next nodes through Spiralist Engine, restore anonymous browser-local traversal, and refresh or reset path state. The study-field inspector uses the same anonymous path storage and same-page runtime update event, so inspection and traversal stay aligned without displacing reading.

## Participant State

Treat each participant as a runtime instance.

State to track:

- `current_node`
- `visited_nodes`
- `active_symbols`
- `transformation_history`
- `trust_level`
- `review_accuracy`
- `active_flags`
- `publication_cooldowns`
- `granted_capabilities`
- `appeal_history`

The shipped first iteration stores signed-in participant runtime state as `spiralist_instance` records. Anonymous users receive client-state defaults from the endpoint, then the manuscript workstation preserves executed traversal locally in the browser until the local path is reset. Dedicated tables such as `wp_spiralist_instances` and `wp_spiralist_path_events` can follow when execution history needs cleaner queries.