Prompt Workspace Architecture - Source Excerpt 04 - Execution Model

Summary

This source excerpt begins near Execution Model and preserves the surrounding evidence from Wiki.FFTAC.org/raw/system-archives/spiralist.org/docs-archive/2026-05-10/docs/prompt-workspace-architecture.md.

**Source path:** Wiki.FFTAC.org/raw/system-archives/spiralist.org/docs-archive/2026-05-10/docs/prompt-workspace-architecture.md

- `steward_ready`

## Execution Model

Prompt execution is server-side.

`PromptRunner` builds execution payloads from prompt contracts, variables, and optional user input. `OpenAIClient` calls the OpenAI Responses API when the optional Spiralist AI Runtime plugin is inactive; when Runtime is active, Workspace defers provider routing there.

Current execution behavior includes public anonymous runs with per-visitor limits, role-based authenticated run limits, stored runs and usage metadata, reusable prompt tests, prompt-governed conversations through `previous_response_id`, fullscreen AJAX chat turns, conversation memory-pressure prompts, signed-in memory condensation, portable conversation exports, prompt flavor exchange artifacts, and sanitized prompt-guided member profile CSS. Conversation and export surfaces must keep safety boundaries explicit and avoid hidden-continuity or policy-bypass claims.

The public `/api-examples/` surface now links the prompt-library API into the broader machine-access guide so consumers can discover public prompt exports without treating the human prompt library as a scraping target.

## REST API Surface

The exact route catalog lives in `wp-content/plugins/spiralist-workspace/includes/Http/RestController.php`. Keep this doc focused on the supported groups:

- prompt CRUD, fork, improve, share, favorite, version, diff, rollback, test, run, and conversation routes
- conversation list/detail/message/condense/portable-export routes
- run list/detail routes
- review, report, appeal, and appeal-resolution routes
- public prompt, featured prompt, category, facet, and public export routes
- reputation and user lookup routes
- admin OpenAI/runtime checks, prompt-test batch runs, and governance-maintenance routes

Prompt payloads from the prompt, review, appeal, featured, and public export endpoints include `review_summary`, `appeal_summary`, and `governance_summary`. The governance summary is the preferred machine-consumer field for deciding whether a prompt is provisional, reviewed, restricted, reverted, archived, official, public-visible, reviewer-visible, stale, urgent, or still waiting for quorum.

Detailed prompt payloads can also include `spiral_script_source`, `spiral_script`, `spiral_script_validation`, and `spiral_script_status` when a prompt has Spiral Script source attached. The public/published save path rejects attached Spiral Script source that fails v0.1 validation, keeping unsafe or structurally invalid symbolic prompt systems out of public publication until revised.

Public prompt index requests accept a `moderation_status` filter, so consumers can request states such as `provisional_public`, `peer_reviewed`, or `official_canon` without scraping labels from the human library.

The public-library API examples now include machine-readable exports for User AI starter prompts and Spiralism prompt builders in addition to the official canon, archive safety review set, governance prompts, peer-reviewed prompts, and facet registry.

Governance-maintenance status is admin-only. `GET /admin/governance-maintenance` reports whether the WP-Cron hook is scheduled, the next UTC run time, and the stored last-run summary. `POST /admin/governance-maintenance` accepts an optional `limit` from 25 to 500 and immediately refreshes the sampled participant state, queue counts, open appeal count, stale/urgent review counts, stale queue samples, automatic fallback actions, and audit record.

## Front-End Rendering

`FrontendController` currently supplies template context for:

- public library sections and filters
- prompt version history and execution history
- prompt flavor exchange view/download controls on prompt dossiers
- member dashboards and shared-with-me lists
- public member profile pages with sanitized profile-local style controls
- run detail pages
- fullscreen-capable conversation transcript pages
- JSON alias endpoints for prompt, run, and conversation listings

The public library and the homepage both consume the same prompt registry, which keeps the public canon, archive prompts, and top-performing prompts aligned.

## Operational Notes

- The Workspace plugin is part of the current live site, not a roadmap item.
- Managed prompts and public prompts share one reader-facing system, but the filesystem registry still matters for official and system-owned prompts.
- The prompt platform is meant to complement the manuscript gateway and publication layer, not displace them.

## Autonomy Requirement

The long-term operating direction is that non-manuscript community publication should not depend on the site owner being online.

- Managed filesystem prompts can stay steward-controlled.
- Community prompts should move toward `draft -> provisional_public -> peer_reviewed -> restricted_review/reverted/archived` rather than waiting on one owner queue.
- Reviewer powers, reports, trust, and appeals should be distributed across trusted participants.
- Steward-style dispute resolution should be distributed across trusted participants rather than collapsing back into admin-only moderation.
- Public machine exports carry moderation and governance-summary state so consumers can tell provisional material from reviewed material and inspect quorum context.
- Scheduled governance maintenance now refreshes the current trust/queue picture, stale-review visibility, open appeal visibility, and reversible automatic fallback actions for missed quorum or stale-risk states; canon-council workflow remains roadmap work.

See [Self-Operation and Peer Moderation](wordpress-runtime/11-self-operation-and-peer-moderation.md) for the roadmap. Do not treat that model as fully shipped until the plugin implements it.

The current plugin implements the first slice of that model. It does not yet mean every governance target in the roadmap is complete.

For testing details, see [Testing Docs](testing/README.md).