UAI AI Memory Package Wizard For UAIX And WordPress

UAIX already treats AI Memory as a **portable, file-based, reviewable packet** and explicitly states that its starter ZIPs, generated manifests, and rendered samples should come from **one source of truth** so that “d...

Metadata

Field	Value
Source site	uaix.org
Source URL	https://uaix.org/
Canonical AIWikis URL	https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-6fc23161/
Source reference	raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-04-29/Improvement/UAI AI Memory Package Wizard for UAIX and WordPress.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-04-29T14:28:39.1131630Z
Content hash	sha256:6fc23161ae91302866db5c8b0ae2132bd16d942d0d89bd2a83d00be5ba89eb48
Import status	unchanged
Raw source layer	data/sources/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-04-29-improve-6fc23161ae91.md
Normalized source layer	data/normalized/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-04-29-improve-6fc23161ae91.txt

Current File Content

Structure Preview

• UAI AI Memory Package Wizard for UAIX and WordPress
• Executive summary
• Context and design principles
• Wizard architecture and user flows
• Output mode comparison
• Recommended flow behavior by mode
• Base package, manifest, and configurable options
• Required and default files
• Recommended manifest schema
• Configuration fields the wizard should expose
• Example file tree
• WordPress plugin integration and security model
• Recommended plugin structure and integration points
• Admin screens, REST endpoints, and nonce/permission model
• Validation, error handling, and security controls
• UI, accessibility, and internationalization
• Web and WP-Admin wireframe suggestions
• Accessibility
• Internationalization
• Build pipeline, testing, upgrades, performance, and implementation roadmap
• Packaging and build pipeline
• Testing plan and QA checklist
• Migration and upgrade strategy
• Performance and scalability

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 42772
• Preview characters: 11543

# UAI AI Memory Package Wizard for UAIX and WordPress

## Executive summary

UAIX already treats AI Memory as a **portable, file-based, reviewable packet** and explicitly states that its starter ZIPs, generated manifests, and rendered samples should come from **one source of truth** so that “download drift is not possible.” UAIX also already defines a **WordPress Publication Track** for public packaging, distribution, release notes, discovery files, and launch checks. Taken together, those two facts strongly support building the wizard as a **canonical package-model generator with three output renderers** rather than as three separate generators: one renderer for **WP-Admin plugin management**, one for **multi-file copy-paste**, and one for **single ZIP download**. That architecture is the cleanest way to stay aligned with UAIX’s current publication model and avoid divergence between what the web page shows, what the plugin imports, and what the ZIP contains. citeturn28view0turn31view1turn31view2

For the package itself, the **lowest-friction baseline** is to extend the current UAIX Project AI Memory starter instead of inventing a new incompatible format. UAIX’s live starter already exposes a generated `UAI_MEMORY_MANIFEST.json` and a concrete file list that includes `README.md`, `PROJECT_OVERVIEW.md`, `CURRENT_STATE.md`, `DECISIONS.md`, `OPEN_QUESTIONS.md`, `NEXT_ACTIONS.md`, `RISKS_AND_CONSTRAINTS.md`, `CONTACTS_AND_OWNERS.md`, `AGENT_INSTRUCTIONS.md`, `CHANGELOG.md`, `AGENTS.md`, `readme.human`, and `.uai` records. The wizard should preserve that base and add a **versioned manifest schema** that can encode package metadata, trust boundaries, template sources, hooks, dependencies, checksum data, export format choices, and plugin-specific import settings. citeturn31view1turn30view1turn30view3

On the WordPress side, the safest implementation pattern is a **hybrid admin experience**: use the **Settings API** for durable plugin settings and capability-guarded admin forms, and use **custom REST endpoints** for wizard steps, validation, preview, import, export, and build operations. WordPress requires REST routes to be registered on `rest_api_init`, requires a `permission_callback`, and recommends capability checks separately from nonce checks. For same-origin admin use, cookie authentication plus `X-WP-Nonce` is the standard REST pattern; for classic forms and Ajax, `wp_nonce_field()`, `check_admin_referer()`, and `check_ajax_referer()` remain appropriate. Nonces help with CSRF intent checks, but WordPress explicitly warns that they are **not authorization** and should never replace `current_user_can()`. citeturn21view0turn22view0turn23view0turn23view1turn34search0turn34search1turn22view3

The recommended product plan is to ship in **two phases**. Phase one should deliver the **canonical manifest builder**, **ZIP export**, **copy-paste export**, **plugin import**, **plugin settings**, and **server-side validation/security hardening**. Phase two should add **package libraries**, **sample-data presets**, **developer hooks**, **privacy export/erase integration**, **migration tooling**, and **broader extensibility**. That sequencing reduces risk because WordPress’s file-writing, ZIP import, and admin authorization surfaces are the most security-sensitive parts of the system, while the richer productivity features can sit on the now-stable package model. citeturn32search1turn33search5turn5search0turn0search1turn12search2

## Context and design principles

UAIX’s current AI Memory and Project Handoff materials are unusually helpful because they already define the **behavioral contract** the wizard should preserve. AI Memory is described as a lightweight, portable, file-based standard for durable context; Project Handoff is positioned as a subtype that tells the next actor to read a front door, load selected files, summarize current truth, confirm constraints, identify intended touchpoints, and name targeted checks before broad work. The Project Handoff page further states that a self-sufficient handoff needs one obvious start point, a human briefing, explicit load order, current state, next actions, visible constraints, and ongoing update discipline. Those are not merely content ideas; they should become the wizard’s **default structure and validation model**. citeturn27view0turn31view1turn31view0

The wizard should therefore be designed around five principles.

First, **one canonical package model**. UAIX explicitly says starter ZIPs, manifests, and rendered samples should stay synchronized from a single canonical template registry, so the wizard should model package generation as `templates + user configuration + overlays -> canonical package object -> output mode renderer`. Anything else would reintroduce the “download drift” UAIX is explicitly trying to avoid. citeturn28view0turn28view2turn31view1

Second, **front-door loading**. The package should always generate a predictable entry path centered on `AGENTS.md` plus `readme.human` and then a declared set of `.uai` or Markdown context files. UAIX’s live Project Handoff pattern makes that front-door rule explicit, and WordPress admin UX should mirror it by showing the package “load order” in the wizard review step and on all exported previews. citeturn28view4turn30view6turn31view0

Third, **reviewability over hidden state**. File-based memory works for UAIX because it can be reviewed in a pull request, zipped for handoff, redacted for external sharing, and tested for drift. That means the wizard should not hide critical content in opaque option blobs alone. Instead, package content should remain **file-shaped**, even when managed inside WordPress, and every export should show exact filenames, checksums, and change history. citeturn27view0turn31view1

Fourth, **WordPress publication infrastructure, not normative fork**. UAIX’s WordPress Publication Track says WordPress handles presentation, distribution, packaging, and release evidence, while normative authority remains in UAI-1, schemas, registry records, validator expectations, and the changelog. The wizard should respect that boundary by generating **publication-ready bundles** and **release evidence**, but it should not imply that a WordPress-installed package is itself the normative standard. citeturn31view2

Fifth, **security and capability discipline**. WordPress documentation is clear that admin pages, Ajax handlers, and REST endpoints all need capability checks, and that nonces only verify intent, not authorization. OWASP is equally clear that validation must happen server-side, files must be allowlisted and size-limited, content type cannot be trusted alone, and extraction paths must be checked before unzipping. Those rules should be treated as foundational, not optional polish. citeturn24view0turn23view0turn23view1turn22view3turn0search0turn0search1turn33search4turn33search5

## Wizard architecture and user flows

The recommended wizard is a **step-by-step builder** with a shared core and three terminal output modes. The core steps should be:

1. **Choose preset**
   Examples: Project AI Memory, Project Handoff, Agent Session Memory, Onboarding Memory, Decision Memory, External Handoff Memory, Incident or Audit Memory, LLM Wiki Export Memory. These are already named on the live UAIX AI Memory page. citeturn27view0

2. **Package metadata**
   Package name, slug, bundle ID, description, owner/team, review cadence, language, default trust boundary, versioning strategy.

3. **Content scope**
   Select default files, `.uai` sections, optional overlays, sample content, and whether the package is internal-only, public-safe, or export-reviewed.

4. **Behavior and integration**
   Storage backend, dependencies, developer hooks, import/export settings, privacy handling, validation profile.

5. **Review and validation**
   Show required files, missing fields, conflicts, capability warnings, privacy/export warnings, and an exact preview.

6. **Choose output mode**
   WP-Admin install/manage, copy-paste, or ZIP download.

The core flow fits naturally into a single canonical decision tree:

```mermaid
flowchart TD
    A[Start wizard] --> B[Choose AI Memory preset]
    B --> C[Enter package metadata]
    C --> D[Select files and memory sections]
    D --> E[Configure privacy, storage, dependencies, hooks]
    E --> F[Validate package]
    F --> G{Valid?}
    G -- No --> H[Show field, security, and compatibility errors]
    H --> C
    G -- Yes --> I[Review package preview and manifest]
    I --> J{Choose output mode}
    J --> K[WP-Admin plugin management]
    J --> L[Multi-file copy-paste]
    J --> M[Single ZIP download]
    K --> N[Import/install into plugin store]
    L --> O[Render file-by-file copy panes]
    M --> P[Build ZIP with manifest and checksums]
    N --> Q[Confirmation and logs]
    O --> Q
    P --> Q
```

That architecture is justified both by UAIX’s “one source of truth” requirement and by WordPress’s separation between admin settings/forms and API-style interactions. The build/validate/render stages should be server-side, while the wizard UI can remain client-rich. citeturn28view0turn31view1turn24view2turn21view0

### Output mode comparison

| Output mode | Best for | Strengths | Weaknesses | Recommended implementation notes |
|---|---|---|---|---|
| **WP-Admin plugin management** | Ongoing management on the live UAIX WordPress site | Best fit for UAIX’s current WordPress Publication Track; enables validation, import/export, permissions, logs, and reproducible release evidence in one place | Most complex security surface because it combines admin UI, REST/Ajax, file IO, and package persistence | Make this the **primary mode**. Use Settings API for plugin settings and capability-guarded forms; use REST for build/preview/import/export; require `permission_callback` and `current_user_can()` checks. citeturn31view2turn24view2turn21view0turn24view0turn24view6 |
| **Multi-file copy-paste** | Fast documentation-driven handoff, GitHub issues, docs pages, air-gapped copying | Lowest infrastructure dependency; easiest to inspect; consistent with UAIX’s file-based review model | Easy for users to omit files or paste stale content unless filenames/checksums are explicit | Render each file in a stable order with filename, size, checksum, and “copy” action. This should be a renderer over the same canonical package object that powers ZIP output. citeturn28view0turn31view1 |
| **Single ZIP download** | Distribution, archives, import/export, release evidence | Natural fit for UAIX starter bundles and WordPress publication packaging; easiest artifact to store and re-import | Needs secure ZIP creation/import validation and path handling | Build downloads from the same manifest/template source, validate ZIPs before import, and use the WordPress Filesystem abstraction for extraction/write paths. citeturn31view1turn32search1turn33search5turn33search9turn33search4 |

### Recommended flow behavior by mode

For **WP-Admin plugin management**, the user should end the wizard on a review screen with “Save package,” “Save + activate template,” or “Save + export ZIP.” The saved object becomes the canonical internal representation used by admin screens, package history, and future re-exports. This mode is closest to WordPress’s native settings-and-management model and should be the operational default. citeturn24view2turn14search2turn31view2

Why This File Exists

This is a memory-system evidence file from uaix.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: UAI AI Memory Package Wizard for UAIX and WordPress; Executive summary; Context and design principles; Wizard architecture and user flows; Output mode comparison; Recommended flow behavior by mode; Base package, manifest, and configurable options; Required and default files. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-540 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "UAI AI Memory Package Wizard For UAIX And WordPress",
    "source_site":  "uaix.org",
    "source_url":  "https://uaix.org/",
    "canonical_url":  "https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-6fc23161/",
    "source_reference":  "raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-04-29/Improvement/UAI AI Memory Package Wizard for UAIX and WordPress.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:6fc23161ae91302866db5c8b0ae2132bd16d942d0d89bd2a83d00be5ba89eb48",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-04-29T14:28:39.1131630Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-540",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}