Visual Guide

Visual Guide

The current four-part 4K field guide shows ROOT internal rules/planning, canonical task and harness/optional-bot TODO observations, Agent 0/X/Y/Z, AGENTA and all ten AUTOBOTS, DATA, CLI/tooling, and named .SYSTEMXP projects together. One overview page is followed by three detailed pages. The diagrams below add text and record-flow explanations. Arrows describe responsibilities and evidence flow; opening an image does not start a worker or install transport. Use the exact command manuals for syntax and permissions.

Animated introduction

Watch on YouTube · Download the 1:50 Full HD MP4 · Download the 4K poster · Chapters and format

The introduction animates the project records, agent responsibilities, ROOT observations, selected reference functions, DATA, and named project scopes. It complements the static field guide and its accessible text; its media edition 1.0 does not relabel the existing alpha.3 field-guide artwork. Find the streaming copy on the Wayne Tech Lab channel; the release downloads remain available independently.

Advanced animated walkthrough

Inside the coordination layer is a 5:54 / 1080p / 24 fps film with 18 native animated scenes and a separate native 4K poster. It develops the records, Agent 0/X/Y/Z/Alpha, AUTOBOT, DATA, ROOT, .SYSTEMXP, profiles, tools, adoption, and evidence boundaries across four parts. The local CLI demonstration and constructed input-token comparison are clearly distinguished from the illustrative app/provider diagrams. No real external Codex job, PR run, native cloud connector, or continuous synchronization is claimed.

Film, captions, prompts, and evidence · 4K poster download · Media release

Four environment cards

Use-case infographics provides separate 4K cards and step-by-step text for ChatGPT + Drive, Codex + GitHub, Dots / Codex Cloud, and Codex / Copilot CLI on a local drive. The source assets travel in .SYSTEMX/MEDIA.

Tier 2: AUTOBOT detail and local DATA

flowchart TD
    Scope["Select one root .SYSTEMX or named child .SYSTEMXP"] --> A0["Agent 0: plan, task routing, integrate, accept"]
    A0 --> Native["Authorized harness workers / configured project tools"]
    A0 --> Y["Agent Y: optional selected external CLI / draft PR"]
    A0 --> Alpha["Agent Alpha / AGENTA.MD / optional agent.a"]
    X["Agent X: observed events and time"] -->|"explicit detail request"| Alpha
    Y -->|"explicit detail request"| Alpha
    Z["Agent Z: fixed evidence review"] -->|"explicit detail request"| Alpha
    Tools["Explicit Tools step / caller tools"] --> Alpha
    Alpha --> Match{"Same selected inputs and request?"}
    Match -->|"yes"| Reuse["Reuse existing request/result and original evidence time"]
    Match -->|"changed / new"| Select["Select only relevant fixed specialist slots"]
    Select --> Panel["Design.MD · Soul.MD · Memory.MD · Rules.MD · Research.MD<br/>Brand.MD · Media.MD · Tokens.MD · Data.MD · Archive.MD"]
    Panel --> Detail["Bounded detail packet / explicit request and completion"]
    Reuse --> Detail
    Detail --> A0
    Native --> Evidence["Original project evidence; canonical task ledger stays with Agent 0"]
    Y --> Evidence
    Evidence --> X
    Evidence --> Z
    Panel -. "safe references only; no automatic scan" .-> Data["Selected DATA: TEMP / LARGE / IMPORTS / RESEARCH<br/>ASSETS / EXPORTS / CACHE / ARCHIVE"]
    Data --> Audit["Exact tracked scaffolds; payloads Git-ignored by default; data audit"]

Loading

Text equivalent: choose one scope and its records first. Agent 0 owns the objective/plan/task ledger and acceptance; X records actual time, Y is the optional external CLI channel, and Z reviews fixed questions. An explicit selected request from these roles or Tools reaches Agent Alpha, which returns only relevant detail from the ten fixed Markdown slots. An unchanged completed request reuses its original result/evidence time. Changed inputs identify stale historical detail and justify a new bounded request. No arrow starts a worker, a recursive check, a model call, or background synchronization. Specialist rules are lower-authority project data. Raw/private/large payloads stay in selected DATA; safe references connect them to the panel. Root/child panels and DATA never inherit each other. See AUTOBOT and Agent Alpha and Local DATA storage.

Full-system overview

Open / download the full 4K JPEG

Read all four pages and their text equivalents. The overview connects one explicit scope, Global context, Master Plan, canonical work, Agent 0/X/Y/Z, Agent Alpha, all ten specialist files, execution tools, DATA, and named children. The detail pages separate the responsibilities so the overview need not carry every implementation limit in small type.

Detail page	What it explains
2. Agent coordination and TODO reconciliation	Bounded task assignment, app workers versus external CLI, actual checks, X evidence, Z review, acceptance and checkpoint
3. ROOT planning, AGENTA, and ten AUTOBOTS	Exact files, specialist responsibilities, selected requests, fingerprints, result reuse, context bounds and authority
4. Scoped ROOT, DATA, and the toolchain	Eight payload folders, tracked scaffold policy, audit limits, explicit root/child routing, versions and recovery

Text equivalent: Agent 0 owns the plan, integration, canonical task ledger, and acceptance within user authority. The harness supplies running agents and tools. Agent X records actual event/time/evidence; Agent Y is an optional selected external CLI lane with separately gated draft-PR lifecycle; Agent Z reviews the fixed 100 questions. Agent Alpha selects requested reference detail from the ten AUTOBOT documents and reuses unchanged results. Root/child DATA remains local payload storage with default Git exclusions. Named .SYSTEMXP children share outer defaults/tools but keep separate facts, tasks, memory, panel and payloads. No arrow grants permission, merges a PR, synchronizes a cloud folder, or starts an automatic review/rebuild loop.

The four-part guide's provenance section links exact-byte metadata, native/export dimensions, and prompts. The images are 3840 × 2160 exports; canvas size does not establish native generated detail.

Historical CLI and project poster

The alpha.5 4K poster and its text equivalent remain available as a frozen Agent 0/X/Y/Z CLI/.SYSTEMXP baseline. The new four-part guide replaces it as the current overview and includes ROOT and observed task-list reconciliation alongside Tier 2. Additive updates preserve older local media; they never delete an existing file merely because the latest template uses a different image name. The optional sibling .systemx → .SYSTEMX alias remains distinct from the internal .SYSTEMX/.systemx/ managed cache. Exact case and alias.

CLI, tools, and named project routing

flowchart LR
    Human["Human / authorized AI app or IDE"] --> SX["systemx: installed management CLI"]
    Human --> Local["Reviewed SYSTEMX.sh / SYSTEMX.ps1"]
    SX --> Outer[".SYSTEMX: shared selected defaults and tools"]
    Local --> Outer
    Outer --> Root["Explicit --root: workspace records"]
    Outer --> Registry["Projects/REGISTRY.json"]
    Registry --> A["Projects/Project-A/.SYSTEMXP"]
    Registry --> B["Projects/Project-B/.SYSTEMXP"]
    A --> A0["Scoped Agent 0: assign / integrate / accept"]
    A0 --> Native["App / IDE bounded workers"]
    A0 --> Y["Agent Y: selected Codex / Copilot / configured CLI"]
    Y --> Git["Task worktree / Git / opted-in draft PR via gh"]
    A0 --> Tools["Configured check / dev / build / deploy"]
    Native --> Evidence["Scoped evidence / Agent X time / Agent Z review"]
    Git --> Evidence
    Tools --> Evidence

Loading

Text equivalent: choose the outer installation before choosing a child. The installed systemx projects --target OUTER_DIR -- ... --project Project-A command selects shared defaults and that child's records. A reviewed local launcher offers the same scoped runtime. Native app workers and Agent Y's external CLI are distinct execution choices; Git/gh and configured project commands remain explicit tools with their existing authority. A child .SYSTEMXP is a record scope, never a nested installation. Tool map.

Shared context, work, time, and review

Text equivalent: keep the researched objective and constraints in shared context; Agent 0 selects and integrates bounded work; the harness supplies actual tools and workers. Agent X records meaningful times, attempts, revisions, and evidence. When selected, Agent Y runs one bounded external CLI task and returns its worktree/commit and optional draft PR for independent project checks. Agent Z reviews the fixed policy at a completion boundary or on request, reusing unchanged proof. Agent 0/user accepts against the original criteria or identifies a concrete gap. Save canonical tasks, generated views, reviewed facts, and a checkpoint. A later authorized turn reads the relevant current state.

This is the practical shared-brain metaphor: useful project knowledge can accumulate across turns. It is not model training, AGI, guaranteed improvement, or an automatic endless work loop. Turn protocol.

From a researched brief to delivery

Text equivalent: this earlier illustration labels six delivery segments as “waves”: research the brief, verify foundations/contracts, perform independent scoped tasks, integrate user journeys, verify/review, then deliver within authority and check the actual target. Each transition requires its agreed evidence. The current planning vocabulary uses milestone → wave → phase → task; a wave groups related phases, while a ready execution batch contains concurrent non-conflicting tasks. The old artwork does not prescribe six levels or counts. Agent X records events throughout; Agent 0 owns plan/task consistency. An independent eligible task may use Agent Y’s selected CLI lane under the same scope, concurrency, cost, and acceptance limits as the app’s workers.

Optional ROOT root node records planning structure without duplicating canonical task state. See ROOT planning and task delta. See the 20-page app walkthrough for the route matrix, research and execution prompts, acceptance gates, and alternative project types.

Multiple chats and bots, one record authority

Text equivalent: several readers/workers can use a selected snapshot. One owner reconciles accepted changes to each canonical record scope. Git, Drive, a connector, or a cloud snapshot adapter supplies transport. Verify saved revision, conflicts, and readback before the next session writes. A URL does not itself grant access, persist changes, or synchronize concurrent edits. See shared workspaces, clouds, chats, and bots.

Folder and record tree

flowchart LR
    Root[".SYSTEMX"] --> Global["GLOBAL / shared context"]
    Root --> Plan["PLAN / Master Plan"]
    Root --> Work["WORK / canonical tasks and focus"]
    Work --> Views["Generated CURRENT and six status views"]
    Root --> Memory["MEMORY / accepted facts and checkpoints"]
    Root --> Agents["AGENTS / 0, optional X/Y/Z/A, registered workers"]
    Root --> Auto["AUTOBOT / ten fixed detail slots + AGENTA.MD"]
    Root --> Data["DATA / exact tracked scaffolds; ignored payloads"]
    Root -. role activation .-> Events["EVENTS / occurrence time and due items"]
    Root -. role activation .-> Jobs["AGENTS/agent.y/JOBS.json / external CLI channels"]
    Root -. role activation .-> Reviews["REVIEWS / policy, requests, scorecards"]
    Root --> Config["project.json / explicit command arrays"]
    Root -. managed install .-> Selected["INSTALLATION.json / selected defaults"]
    Root -. managed install .-> Cache[".systemx / retained releases and operation logs"]

Loading

Text equivalent: Global and Plan preserve purpose; Work owns task state and focus; Memory holds reviewed knowledge; Agents holds scoped role notes. Activated X/Y/Z records add event/due ledgers, CLI job channels, and fixed-policy review records. Configuration selects explicit commands. Managed metadata selects versioned defaults. The internal .SYSTEMX/.systemx/ cache differs from the optional sibling alias.

The public distribution stays blank with only Agent 0 registered. New role activation preserves existing records and starts no runtime process. Generated views come from canonical records, not independently edited status lists. Standard format · Exact casing.

Named project scopes

flowchart TD
    Root[".SYSTEMX / shared tools and selected defaults"] --> Outer["Portfolio Global, Master Plan, Agent 0"]
    Root --> Registry["Projects/REGISTRY.json / explicit selection"]
    Registry --> App["WebApp/.SYSTEMXP"]
    Registry --> Research["Research/.SYSTEMXP"]
    Registry --> Bot["BotOps/.SYSTEMXP"]
    App --> AppRecords["App context, tasks, memory; optional X/Y/Z and AUTOBOT/DATA"]
    Research --> ResearchRecords["Research context, tasks, memory; optional X/Y/Z and AUTOBOT/DATA"]
    Bot --> BotRecords["Operations context, tasks, memory; optional X/Y/Z and AUTOBOT/DATA"]

Loading

Text equivalent: one outer installation provides defaults, while each named child owns separate context, plans, tasks, and memory. X/Y/Z activation is scoped. The supported path is .SYSTEMX/Projects/NAME/.SYSTEMXP; a nameless Projects/.SYSTEMXP and nested .SYSTEMX installations are unsupported. No scope or role is a process tree or an authentication boundary. SYSTEMX PROJECTS.

Reuse a review or assess a real change

flowchart TD
    Boundary["Completion boundary or requested review"] --> Match{"Matching report exists<br/>and inputs unchanged?"}
    Match -->|Yes| Reuse["Reuse saved scorecard and evidence"]
    Match -->|No| Assess["Agent Z / same versioned 100 questions"]
    Assess --> Report["Scorecard / unknowns / evidence / delta"]
    Reuse --> Decision["Agent 0 or user / original acceptance criteria"]
    Report --> Decision
    Decision -->|Met| Done["Accept and checkpoint"]
    Decision -->|Concrete gap| Next["Next bounded action or real blocker"]

Loading

Text equivalent: review when needed, reuse identical inputs, and compare only matching subjects/policies. Changed policy requires a new baseline. The acceptance owner chooses completion or a bounded next step. Neither a score nor a due item automatically reopens tasks, executes jobs, or repeats the pipeline. Agent X · Agent Z · 100 questions.

Diagram sources, downloads, and accessibility

The brand is the standalone .SYSTEMX wordmark. Maintainer attribution stays separate in project information. The original imagegen logo remains current. The current four-part field guide is generated raster artwork with retained prompts, exact export metadata, and accessible text equivalents. Three focused workflow diagrams retain their examined Agent 0/X/Y/Z baseline as editable Mermaid sources, PNG previews and SVG exports in the repository's asset directory. The live Tier 2 and scope diagrams on this page show Agent Alpha/AUTOBOT/DATA; the refreshed four-page series combines those responsibilities with ROOT planning/rules and observed harness/optional-bot task-list reconciliation. The earlier full-system poster, six-step illustration, and four environment cards retain their historical baselines. The current edition 2.0 white paper examines alpha.4 with four original architecture, coordination, scope, and input-accounting figures. Its publication release is alpha.5; the four-page raster field guide retains media edition alpha.3.

Diagram	Source / explanation	Export
Current four-part system field guide	Four pages, accessible detail and provenance	Overview · Agent coordination · AUTOBOT panel · DATA/projects
Shared-context coordination, earlier four-role baseline	Mermaid	SVG · PNG
Project waves, earlier four-role baseline	Mermaid	SVG · PNG
Shared workspace, earlier four-role baseline	Mermaid	SVG · PNG

Text equivalents and alt text accompany the diagrams. Color is not the sole indicator of meaning. Mermaid source also remains readable when a viewer cannot render it. Update the diagram, explanation, and exports together when behavior changes. GitHub's diagram documentation.

Four-role delivery gates

flowchart TD
    Context["Selected scope, Global context, Master Plan, TASKS.json"] --> A0["Agent 0: assign, integrate, verify, accept"]
    A0 --> App["Harness-native bounded workers"]
    A0 --> Y["Agent Y: task-selected installed CLI"]
    Y --> Local["Pinned executable; isolated worktree; scoped commit"]
    Local --> Draft["Optional authorized draft PR"]
    App --> Checks["Agent 0: original project check evidence"]
    Local --> Checks
    Draft --> Checks
    Checks --> Z["Agent Z: matching 100-question review"]
    Z --> Accept["Agent 0/user: criteria met or concrete gap"]
    Accept --> Ready["Accepted done + unchanged base: separate PR-ready"]
    Accept --> Cancel["Recorded cancelled: separate PR-close; retain work"]
    Ready --> External["Separately authorized merge outside Agent Y"]
    External --> Cleanup["Merged + accepted + exact owned head: verified bundle then cleanup"]
    A0 -. observations .-> X["Agent X: occurrence/recording time, revision, original evidence"]
    Checks -. observations .-> X
    Cleanup -. observations .-> X

Loading

Text equivalent: the canonical ledger remains under Agent 0. App workers and Agent Y are alternative bounded execution paths; they share one project budget. Y chooses a provider per task, pins the local executable, and returns a worktree and scoped commit. An opted-in draft PR may exist before independent project checks. X records observations without accepting tasks or running a scheduler; Z reviews evidence without granting authority. Agent 0/user records acceptance or cancellation. Ready, close, merge, and archived cleanup remain separate gates. A cancelled unmerged branch/worktree stays available for manual review. Agent Y has no merge command. Readback and recovery details are in Agent Y.

ROOT request, planning, and task-delta diagrams

The optional ROOT guide includes editable Mermaid views of originating/delegated requests, the flexible milestone/wave/phase/task structure, and many-to-many observed harness/cloud mappings. These complement the refreshed ROOT-aware four-page artwork. Canonical task status remains in WORK/TASKS.json; local observations are not live connections. The delta is read-only; Agent 0 reconciles through actual authorized tools and retains external readback. One item may cover several scoped task IDs, and optional bot assessment requires a real bot mapping. Completed execution never means automatic task acceptance.