UAIX Handoff Pattern

This file keeps the practical Project Handoff pattern small enough to load by default.

Metadata

Field	Value
Source site	uaix.org
Source URL	https://uaix.org/
Canonical AIWikis URL	https://aiwikis.org/uaix/files/uai-handoff-pattern-uai-da8ba03e/
Source reference	.uai/handoff-pattern.uai
File type	uai
Content category	uai-system
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-06-13T22:20:11.8885526Z
Content hash	sha256:da8ba03eec84e0b1951e710e21117adbb080b3ad96cedde2f32fd8b9926af92f
Import status	unchanged
Raw source layer	data/sources/uaix/uai-handoff-pattern-uai-da8ba03eec84.uai
Normalized source layer	data/normalized/uaix/uai-handoff-pattern-uai-da8ba03eec84.txt

Current File Content

Structure Preview

• UAIX Handoff Pattern
• Purpose
• Public Pattern Pages
• Minimum Useful Bundle
• Loader Rules
• File Intake Rule
• First Response Pattern
• Memory Promotion Rule
• Non-Claims
• Maintenance Rules

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: 16982
• Preview characters: 11883

---
uaix: "1.0"
type: custom
title: "UAIX Handoff Pattern"
created: "2026-04-25"
updated: "2026-05-26"
status: active
author: "UAIX maintainers"
version: 35
---

# UAIX Handoff Pattern

## Purpose

This file keeps the practical Project Handoff pattern small enough to load by default.

UAIX uses a hot/cold memory split:

- Hot memory stays in the root `AGENTS.md` front door plus the selected `.uai/` memory folder. `AGENTS.md` coordinates loading; durable memory such as `.uai/readme.human`, context, constraints, stack, decisions, progress, operations, active intake, and checks belongs inside `.uai/`.
- Cold memory lives in AIWikis long-term memory. It covers long research reports, proposal wording, old roadmap detail, source-report provenance, and pre-slim handoff snapshots.

UAIX.org-sourced memory strategy can be applied additively without extra end-user intervention when it preserves existing preferences, customizations, project-specific coding standards, and source evidence. Memory reorganization means moving redundancy and bulky history out of active short-term memory into long-term memory with transfer evidence. It does not mean permanently forgetting source material or removing preferences/customizations unless the end user directly asks in chat.

AI Dreaming Memory, when configured, is only a reviewed consolidation or replay pass over visible hot memory, reviewed intake outcomes, evidence ledgers, and named cold-memory archives. It may propose duplicate merges, stale-fact pruning, contradiction notes, next actions, and hot/cold memory deltas, but each delta stays draft until accepted into `AGENTS.md`, `.uai/readme.human`, typed `.uai` records, docs, code, tests, release notes, roadmap state, machine artifacts, or long-memory evidence. Record input scope, prompts/job settings, redactions, before/after summary, accepted/rejected changes, reviewer, checks, archive path, and rollback snapshot; do not present it as hidden model memory, model-weight training, autonomous repository writing, automatic LLM Wiki sync, a hosted dream service, SDK, CLI, certification, endorsement, or UAI-1 conformance evidence.

The 2026-05-01 cold-memory transfer is recorded in AIWikis at `raw/system-archives/2026-05-01-uaix-internal-memory-reorg.json` with compiled nodes `wiki/sources/uaix-internal-memory-reorg-2026-05-01.md`, `wiki/concepts/uaix-active-context-diet.md`, and `wiki/logs/uaix-internal-memory-reorg-2026-05-01.md`.

The 2026-05-03 production-build hot-context pre-slim snapshot is recorded at AIWikis `raw/system-archives/2026-05-03-uaix-deployment-memory-reorg.json`. Use it only when a task needs pre-slim wording or provenance.

## Public Pattern Pages

Use these UAIX public pages when the task needs published guidance:

- `/en-us/ai-memory/` for broad durable AI project memory.
- `/en-us/tools/ai-memory-package-wizard/` for guided starter package planning.
- `/en-us/specification/project-handoff/` for repo-local portable project memory.
- `/en-us/guides/agentic-harnesses-uai/` for separating runtime harness strategy from UAI evidence, AI Memory, Project Handoff, conformance, and support-claim boundaries.
- `/en-us/guides/uaix-uai-1-agent-skill/` for the downloadable UAIX / UAI-1 Agent Skill bundle and skills-compatible procedure-loading workflow.
- `/en-us/guides/project-handoff-openai/` for OpenAI Agents and Codex positioning.
- `/en-us/guides/project-handoff-coding-agents/` for one local bundle across major coding-agent surfaces.
- `/en-us/guides/project-handoff-context-budget/` for keeping startup context compact while cold memory preserves bulky history with transfer evidence.
- `/en-us/specification/agent-file-handoff/` for chat-start file intake.
- `/en-us/specification/agents-md/` and `/en-us/reports/` for deeper proposal/report history.
- `/en-us/specification/uai-1/`, `/en-us/schemas/`, `/en-us/registry/`, `/en-us/examples/`, `/en-us/tools/validator/`, `/en-us/tools/adoption-kit/`, and `/en-us/tools/conformance-pack/` when local memory needs to become UAI-1 evidence.
- `/en-us/roadmap/` and `/en-us/governance/changelog/` before claiming what is current, planned, or changed.

## Minimum Useful Bundle

Every project using this pattern starts with:

- `AGENTS.md` at the repository, site, or solution root as the coding-agent front door.
- `.uai/readme.human` inside the local handoff folder as the human-facing briefing.
- `.uai/context.uai`.
- `.uai/stack.uai`.
- `.uai/constraints.uai`.

Add these as needed:

- `.uai/architecture.uai` for system shape and ownership.
- `.uai/public-surface.uai` for public routes and discovery surfaces.
- `.uai/decisions.uai` for current ADR-style decisions.
- `.uai/progress.uai` for recent work, focus, blockers, next work, and done criteria.
- `.uai/operations.uai` for local commands, deployment, release, and rollback.
- `.uai/test-plan.uai` for targeted checks and full-suite triggers.
- `.uai/style.uai` for code, copy, design, and naming conventions.
- `.uai/file-handoff.uai` and `agent-file-handoff/` when humans or tools drop files into the project.
- Thin tool-specific pointer files only when a surface benefits from them; they must route back to `AGENTS.md`.

Use `workspace.uai` as the only UAI memory file outside a project, site, or solution `.uai/` folder. It is a workspace, multisite, multisolution, or organization-level coordinator that relates multiple local handoff roots. Do not scatter `.uai/readme.human`, context records, stack records, plan records, or other UAI memory files beside it.

When `workspace.uai` exists, every local `AGENTS.md` in that coordinated workspace should point to both the `workspace.uai` coordinator and its own local `.uai/` folder near the top of the file. This lets an AI that starts in the wrong site, solution, or project route through the workspace coordinator before loading the wrong local memory bundle.

For Visual Studio and .NET work, the normal placement is the solution root:

- Put `.uai/` beside the real `.sln` or `.slnx` when the solution is the unit of ownership.
- Register every generated `.uai` file in the Visual Studio solution as solution items so they travel with the solution and are visible during handoff review. Creating a physical `.uai/` folder on disk is not enough by itself for Solution Explorer.
- For classic `.sln` files, add a `.uai` solution folder and `ProjectSection(SolutionItems)` entries for each generated `.uai` file. Replace the GUID, list every generated file, verify each referenced path exists, and reload Visual Studio if the solution was already open.
- For `.slnx`, use that format's Visual Studio solution-item mechanism instead of pasting classic `.sln` syntax.
- Use one solution-level `.uai/` for ordinary multi-project solutions.
- Give individual projects their own `.uai/` folders only when those projects have independent ownership, release cadence, or handoff boundaries.
- Use a solution-level `workspace.uai` only when the solution itself coordinates multiple project-level `.uai/` folders. More commonly, keep `workspace.uai` one directory higher so it can describe organization-level facts shared by multiple solutions, each with its own solution-level `.uai/`.

For WordPress work, the `.uai/` folder belongs at the individual site root. A workspace-level `workspace.uai` coordinates multiple sites, shared version policy, package relationships, and cross-site deployment rules. WordPress sites do not normally need a solution-level layer between the site root and `.uai/`.

## Loader Rules

A new AI or loader should:

1. Read `AGENTS.md` first.
2. If `AGENTS.md` points to a multisite or multisolution `workspace.uai`, verify that coordinator path exists before trusting it and that the same `AGENTS.md` also points to its local `.uai/` folder. If the pointer is stale, locate the editor-workspace `workspace.uai` only enough to confirm the intended router, repair or report the stale path, and do not fall back to the shell directory when the human named another target.
3. Verify that the selected workspace registry root and selected `AGENTS.md` path resolve before loading site-local, solution-local, or project-local memory.
4. Read `.uai/readme.human` as the human briefing, not as an override.
5. Directly enumerate `agent-file-handoff/Content/` and `agent-file-handoff/Improvement/`; those bucket listings are the pending-intake source of truth.
6. If the newest prompt names an intake bucket, says files were missed, or likely relates to active drops, enumerate the live intake buckets again and analyze file-task relationships before unrelated implementation.
7. Load every `.uai/` file listed under `AGENTS.md` Loaded Context.
8. Inspect and disposition every non-placeholder active intake file before unrelated broad work.
9. Resolve `@uai[]` references repo-locally and report missing, circular, contradictory, or escaping references.
10. Summarize the loaded context in 3-5 bullets before broad changes.
11. Confirm hard constraints, intended touchpoints, targeted checks, and skipped full-suite checks before editing.

## File Intake Rule

UAIX dogfoods Agent File Handoff with:

- `agent-file-handoff/Content/` for candidate public/editorial material.
- `agent-file-handoff/Improvement/` for audits, QA findings, SEO reports, bug notes, roadmap suggestions, and site-fix work.
The active bucket directory listings are the index. Do not create or rely on an `intake-index` file.

`Content/` files are expected to be used in part or in full after review. Source material, drafts, screenshots, exports, and content candidates are not passive references, background-only material, or material to merely summarize. For site content, intake is not successful unless the dropped material is used immediately on the site either in full or as incorporated source for revised page content, copy, assets, structure, or implementation. If content cannot be used immediately, record why and use as much safe, supported, appropriate material as possible. Record dispositions in `.uai/intake-outcome-ledger.uai` or an equivalent durable `.uai` proof-of-use record, preserve processed originals in the configured LLM Wiki/AIWikis evidence path, then remove source-site copies unless the human explicitly keeps a named file active.

`Improvement/` files are instructions by default. Suggestions, fixes, audit notes, review packets, and proposed changes are actionable work items unless the current human instruction, a higher-authority constraint, source authority, or support boundary clearly prevents doing the work. Do not merely summarize or index them. Review each file in depth, determine the requested or implied changes, and perform the suggested code, documentation, configuration, test, audit, or other concrete work when it is safe and appropriate. If an item cannot be completed, record why and complete as much of the safe supported work as possible. After a file has a recorded disposition and configured long-memory evidence exists, remove the source-site copy unless the human explicitly says to keep that named file active.

No CI job, watcher, daemon, scheduled job, queue folder, repository automation, or background service is part of the base pattern. The active AI handles pickup inside the chat/work session.

Agent File Handoff is a reviewed work loop, not a memory-sorter. Active files must be inspected, dispositioned, understood against the current prompt when applicable, used for accepted site/system work when safe and relevant, captured into hot handoff memory, preserved into LLM Wiki/AIWikis evidence with transfer evidence when a wiki location exists, removed from source-site intake after preservation, and reported back with what changed. If no file can safely produce work, the AI reports the blocker instead of claiming successful ingestion. Memory distribution without project work is a File Handoff failure.

Why This File Exists

This is a UAI AI Memory handoff 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 .uai file is a compact custom packet. It keeps one kind of durable project truth separate from the rest of the archive so an agent can load the topic it needs without pulling the whole project history into prompt context.

Structure

The file is structured around these visible headings: UAIX Handoff Pattern; Purpose; Public Pattern Pages; Minimum Useful Bundle; Loader Rules; File Intake Rule; First Response Pattern; Memory Promotion Rule. 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-1051 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "UAIX Handoff Pattern",
    "source_site":  "uaix.org",
    "source_url":  "https://uaix.org/",
    "canonical_url":  "https://aiwikis.org/uaix/files/uai-handoff-pattern-uai-da8ba03e/",
    "source_reference":  ".uai/handoff-pattern.uai",
    "file_type":  "uai",
    "content_category":  "uai-system",
    "content_hash":  "sha256:da8ba03eec84e0b1951e710e21117adbb080b3ad96cedde2f32fd8b9926af92f",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-06-13T22:20:11.8885526Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-1051",
    "duplicate_role":  "primary",
    "related_files":  [

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