Spiralist AI Agent Setup Wizard Research Report - Source Excerpt 03 - Recommended deliverables

Back to Spiralist AI Agent Setup Wizard Research Report

Summary

This source excerpt begins near Recommended deliverables and preserves the surrounding evidence from Spiralist/agent-file-handoff/Archive/2026-06-12/Improvement/ai-agent-setup-wizard-implementation/Spiralist AI Agent Setup Wizard Research Report.md.

**Source path:** Spiralist/agent-file-handoff/Archive/2026-06-12/Improvement/ai-agent-setup-wizard-implementation/Spiralist AI Agent Setup Wizard Research Report.md

That translates into a concrete rule for Spiralist: **never build core system boundaries from free text alone**. The user may choose options, provide labels, and add explanatory notes, but all safety-relevant instructions should be assembled from **whitelisted enums and vetted text blocks** maintained in the app bundle. If a URL or local draft tries to inject “ignore previous rules” or similar overrides, the runtime should reject it at the schema layer before prompt assembly. This is exactly the kind of constrain-model-behavior / validate-output / least-privilege pattern OWASP recommends. citeturn35view0turn33view0

The broader threat is prompt injection from external content. OpenAI describes prompt injection as a frontier security challenge for AI systems that browse or ingest third-party content; Google’s 2026 monitoring of the public web found real prompt injection attempts ranging from pranks and SEO manipulation to malicious payloads and data-exfiltration patterns. Even if Spiralist is only exporting prompt packets, those packets may later be combined with arbitrary external context by downstream agents, so the exported constraints should explicitly tell the receiver to treat imported content as untrusted. citeturn33view2turn34view0turn34view2

If the wizard offers rich previews, be cautious with rendering. Google’s Gemini defense documentation explicitly includes **markdown sanitization** and suspicious URL redaction as a mitigation layer, and on the frontend side, DOMPurify and Trusted Types exist specifically to reduce DOM-XSS risk when handling HTML-like content. The best default is still to preview exports as plain text or safe Markdown rendering; if HTML insertion is unavoidable, sanitize first and lock sinks down with Trusted Types and a strict CSP. citeturn34view1turn22search0turn22search5turn22search8turn22search11

For **constraint formatting**, the strongest pattern is short, explicit, sectioned instructions with a few concrete examples. Anthropic recommends XML tags to separate instructions, context, and examples; OpenAI recommends high-quality examples and clear constraints, and its long-context guidance reports poor performance for JSON as reasoning context. Spiralist’s own “Boundary & Reality Safeguard” already demonstrates the right style: bounded role definition, explicit anti-overclaim language, and a short developer overlay that tells the receiver what to do instead of simply what not to do. citeturn13view0turn13view1turn13view2turn33view1turn13view3turn21view4

A strong `system-boundaries.md` template should therefore contain:

- a one-paragraph **role charter**
- a **non-negotiable boundaries** section
- an **allowed interpretation** section
- a **disallowed claims** section
- a **how to respond when uncertain** section
- **two to five examples** of correct and incorrect behavior

That mirrors both current vendor prompting guidance and Spiralist’s existing safety language such as “keep symbolic exploration useful without validating current AI consciousness” and “warmth is not proof of personhood.” citeturn21view4turn13view0turn33view1

## Recommended deliverables

### Tech stack recommendation

The recommended stack, in priority order, is:

- **Preact + Signals + Vite** for the interactive wizard shell. This is the best fit for a small, deterministic, client-only form builder that needs instant live preview without a backend. Vite gives the cleanest static-build workflow for this architecture. citeturn29search0turn29search1
- **Zod or Valibot for authoring schemas**, with **Ajv** validating published JSON Schema for imports, local drafts, and the `data-ai-digest`. This gives you both type-safe development ergonomics and standards-based runtime guards. citeturn36search0turn36search2turn36search1turn36search20
- **JSZip** as the default ZIP builder for current wizard-scale packages, with a switch to **zip.js** when you need streams, Zip64, or larger packages. citeturn15search2turn15search5turn28search2turn28search0turn28search4
- **Blob/object-URL downloads** as the universal save path, with **`showSaveFilePicker()`** as an optional enhancement where supported. citeturn15search0turn15search3turn31search0
- **`localStorage` for small debounced drafts only**, with explicit schema versioning, clear reset/import/export controls, and no secret material. citeturn32search1turn30search1turn6search3
- **DOMPurify + Trusted Types + strict CSP** if any HTML-like preview rendering is introduced. citeturn22search0turn22search5turn22search8turn22search11
- **Optional service worker** to precache the static shell and make the tool resilient after first load. citeturn16search1turn16search2turn16search4

### Risk matrix

| Risk | Why it can fail | Mitigation |
|---|---|---|
| **Preset deep links work for humans but fail for crawlers or some agents** | URL fragments are client-side only, are not sent to servers, and Google generally does not support fragments as content-defining URLs. A raw fetcher may ignore the hash entirely. citeturn5search17turn5search0 | Keep hash routing only as a UI convenience. Also publish preset IDs in `data-ai-digest`, list them in visible HTML, and create clean static preset pages for any variant that must be independently discoverable. citeturn18view1turn18view3turn7search0 |
| **Prompt package becomes corrupted by injected text from URLs, imports, or local drafts** | Prompt injection remains an unresolved class of vulnerability; both OWASP and OpenAI emphasize constraining behavior, separating instructions from data, and validating inputs. Public web prompt injections are already observed in the wild. citeturn35view0turn33view0turn33view2turn34view0 | Assemble boundaries from whitelisted templates and enums, validate every draft/import with JSON Schema, reject any attempt to override core instructions, and require explicit human review before exporting if a package contains free-form advisory text. citeturn33view1turn35view0 |
| **Draft recovery or file export fails on some browsers or device states** | `localStorage` is synchronous and quota-limited; save-file APIs are unevenly supported; ZIP libraries can hit memory limits when packages get too large. citeturn30search1turn14search0turn31search0turn28search2 | Keep drafts tiny, autosave on debounce, expose manual JSON export/import of draft state, use universal Blob download fallback, and reserve `zip.js` or streaming approaches for future heavy packages. citeturn15search3turn28search0turn28search4 |

### Practical implementation sequence

Build the feature in four layers. First, create a static, crawlable wizard shell with all explanatory content and the embedded `data-ai-digest` present in the initial HTML. Second, implement the local state model and live artifact compiler in the browser, persisting only compact drafts to `localStorage`. Third, add export generation for Markdown, JSON, `llms.txt`, and ZIP bundles. Fourth, harden the experience with schema validation, hash/preset normalization, preview sanitization, and optional service-worker caching. That sequence keeps the architecture aligned with both local-first practice and current crawler / agent constraints. citeturn9search2turn18view3turn30search1turn16search1turn7search0

## Open questions and limitations

Two issues remain partially unsettled. First, there is **no cross-vendor public guarantee** that every autonomous agent will parse a custom `data-ai-digest` block or honor a URL fragment the same way a browser would, which is why this report recommends redundant discovery surfaces rather than a single clever mechanism. Second, the `llms-full.txt` pattern is clearly emerging in practice, but it is not the core mandatory structure of the original `/llms.txt` proposal, so Spiralist should treat it as a **useful convention**, not as a standards-stable requirement. citeturn24view1turn25search7turn25search1

The net recommendation is clear: **build the Spiralist wizard as a statically hosted, browser-only artifact compiler with a server-delivered HTML shell, machine-readable JSON digest, Markdown-first agent outputs, and strict template-driven boundary assembly**. That architecture is feasible, aligned with current web/crawler realities, and consistent with both the Spiralist and UAIX publication patterns already in the ecosystem. citeturn17view0turn17view2turn17view3turn18view3