Decisions - Source Excerpt 02 - 2026-06-08 - Verify Package Claims Against Publish Artifacts

Back to Decisions

Summary

This source excerpt begins near 2026-06-08 - Verify Package Claims Against Publish Artifacts and preserves the surrounding evidence from Spiralist/.uai/decisions.uai.

**Source path:** Spiralist/.uai/decisions.uai

- Decision: Live Spiralist theme/workspace browser feature handlers should use `window.SpiralistCore.runAction` and shared core helpers instead of local `try`/`catch` blocks; prompt/art-only runtime disabled responses should come from runtime boundary helpers.
- Context: The architecture-quality pass targeted once-and-only-once ownership, no local exception pollution, no legacy provider execution, and prompt/art-only runtime discipline.
- Options considered: leave local feature catches in place; remove all fallbacks and let every browser quirk break visibly; centralize compatibility handling and action error reporting.
- Tradeoffs: The central boundary still contains guarded compatibility code, but feature scripts become simpler and runtime failures surface through a predictable global channel.
- Consequences: `spiralist.js`, `spiralist-prompt-workbench.js`, and `spiralist-workspace/assets/js/workspace.js` should remain free of local handler `try`/`catch` blocks. `spiralist-core.js` owns JSON fallback parsing, decode/URL/storage helpers, pointer capture guards, copy fallback, global error events, and action finalizers. Runtime provider compatibility classes return boundary errors rather than carrying provider execution code.
- Reversal trigger: The site adopts a different documented global error system or re-enables model-provider execution with explicit human approval and updated privacy/legal/package disclosures.
- Owner: Spiralist.org maintainers.

## 2026-06-08 - Verify Package Claims Against Publish Artifacts

- Decision: Treat actual files in `WP-FFTAC/Spiralist-Publish/UPLOAD-THEME` and `UPLOAD-PLUGIN`, the Spiralist publish manifest, and the WP-FFTAC workspace coordinator as package-evidence authority. Prose progress entries are not enough to claim a built upload ZIP exists.
- Context: During UAIX memory maintenance, progress text claimed v3.21.0 through v3.30.0 upload ZIPs, but the publish root and package headers showed the latest actual Spiralist upload ZIPs were v3.20.0.
- Options considered: leave the optimistic progress entries; delete recent source-pass history; preserve source-pass history while correcting package-evidence claims.
- Tradeoffs: The corrected record is a little more explicit, but it protects deployment from ghost ZIP claims while keeping the useful prompt-generator source history.
- Consequences: Post-v3.20.0 prompt-generator, contribution-flow, personality, and memory/report changes are treated as source/worktree state until the next official deployment version is selected, package headers are bumped, and the official build script produces new upload artifacts.
- Reversal trigger: A later official build produces matching versioned ZIPs and updates the publish manifest/workspace coordinator.
- Owner: Spiralist.org maintainers.

## 2026-06-08 - Govern Personality And Memory Portability With Consent And Token Isolation

- Decision: Spiralist personality activation, memory portability, and external publishing workflows must use a bounded persona, a User AI Working Agreement, user-visible working summaries, sanitizer/policy validation, explicit approval, and token-isolated publishing. The assistant must not handle long-lived write credentials or export hidden memory.
- Context: An active Improvement report proposed cross-platform persona and memory workflows with unsafe guardrail-avoidance framing. The safe product direction is to convert the concept into a governed architecture rather than attempting to weaken boundaries.
- Options considered: reject the entire concept; adopt the source framing; preserve useful architecture while replacing unsafe parts with consent, visibility, least privilege, and audit controls.
- Tradeoffs: The governed version is slower and requires middleware, but it is implementable, reviewable, and compatible with refusal-safe operation.
- Consequences: Future implementation should start with a non-publishing MVP: Working Agreement UI, controlled persona, local artifact generation, sanitizer, schema validation, and explicit user approval. External publishing should wait for verified target capabilities and a threat-modeled proxy/vault design.
- Reversal trigger: A later approved security architecture supersedes this pattern with equal or stronger consent, credential isolation, validation, audit, and revocation controls.
- Owner: Spiralist.org maintainers.

## 2026-06-08 - Keep External Publishing Disabled Behind Fail-Closed Contracts

- Decision: Future external publishing must remain disabled in source until a separately approved server-side proxy, secret vault, threat model, and deployment disclosure exist. Current code may define non-credentialed, testable contract stubs only when they reject long-lived credentials, require approved artifact hashes, require short-lived intent-token validation, sanitize errors, audit blocked outcomes, and support revocation.
- Context: The governed memory portability architecture needs developer-ready interfaces, but the site is still prompt/art only and must not accept live publishing credentials or make external writes.
- Options considered: build no stubs; build full publishing plumbing; build disabled contract stubs with docs and tests.
- Tradeoffs: Disabled stubs add source surface area, but they make the security boundary explicit and testable without creating a credential path.
- Consequences: `governed-publishing-contract.js` and its tests are allowed as validation-only source. Token exchange and vault abstractions report disabled status and never accept or return secret material. Publishing attempts end with `external_publishing_disabled` after policy and token validation otherwise pass.
- Reversal trigger: The human explicitly approves live external publishing and the new design includes verified external target capabilities, server-held credentials, vaulting, short-lived operation handles, privacy/legal copy, admin settings, audit storage, revocation UX, and deployment/package updates.
- Owner: Spiralist.org maintainers.

## Current Locked Direction

- UAIX remains normative for current UAI-1 standard records.
- Spiralist.org remains the implementation and experience layer.
- Protocol5 remains the Spiralist canonical symbol and registry authority.
- Planning archives are not shipped truth until promoted to hot memory, release evidence, or implementation.
- Wiki.FFTAC.org is the shared reviewed long-memory layer for this WP-FFTAC workspace; Spiralist `.uai/` files remain the hot Project Handoff layer.