Anti Drift and Long Running Work

Anti-drift and long-running work

The objective is to keep a project moving toward its agreed outcome across many tasks, agents, and sessions. .SYSTEMX makes the current state and the reasons behind it inspectable. It helps expose drift; it cannot force an LLM to remain correct or replace review.

Read Daily workflow first. Use Prompt cookbook for reusable execution, checkpoint, recovery, and review requests.

What drift looks like

Symptom	Useful control	What still needs judgment
A session starts solving a different problem	Global constraints, original acceptance criteria, current focus	Whether a requirement legitimately changed
Completed work is repeated	Canonical task IDs, evidence, exact next action	Whether newer changes invalidate earlier proof
Agents implement overlapping changes	Bounded assignments, dependency ordering, shared-resource ownership	Whether work can safely run in parallel
A hypothesis becomes a supposed fact	Scoped agent notes and reviewed promotion into project memory	Whether the evidence supports the conclusion
“Done” means only that a command exited	Review against outcome-specific acceptance criteria	Whether source, deployment, and operational proof are sufficient
A new chat loses the thread	Dated checkpoint and bounded context with source references	Which old observations must be rechecked

When a requirement changes, record the decision, its source, and its effect on scope, tasks, and acceptance. Preserve the superseded reasoning where useful. Do not quietly rewrite the goal to make an incomplete result appear successful.

The 10,000+ event ambition

The founder's goal is continuity through 10,000 or more task-based events until a process, idea, or application reaches its accepted outcome. Here “event” is a plain-language description: a task assignment, status transition, check, review, or handoff. Several events may belong to one task. Event count is not a measure of completed features, model turns, or product quality.

The current release has a file-based task ledger, status history, evidence references, Markdown checkpoints, and optional Agent X event/due records plus Agent Z fixed-policy review scorecards. It is not an event-processing service, and it does not capture every model/tool event automatically. There is no published 10,000-event performance benchmark or guarantee of unattended execution. Actual work remains subject to the harness's session, context, tool, budget, permission, and availability limits.

Plan in bounded batches

1. Define the outcome and acceptance criteria in the Master Plan.
2. Break the next milestone into tasks with explicit dependencies and owners.
3. Select a small active focus; use the ledger for the larger backlog.
4. Give each worker the relevant task and source evidence, not the whole archive.
5. Review results, integrate changes, and run relevant combined checks.
6. Save durable facts, current state, and the exact next action before a handoff.
7. Recheck changing state on resume and select the next ready batch.

Set a practical batch boundary such as a reviewed feature, a resolved incident, or a completed research question. Do not prefill thousands of speculative tasks just to reach an event target. Refine future work as evidence changes the plan. The current focus supports at most ten task pointers; this is not a worker limit or a cap on the complete ledger.

Load enough context to continue correctly

Use the selected defaults and the project's current records in START-HERE.md order. A bounded context packet is a starting point. Read full acceptance criteria, dependency records, and original evidence when needed. Truncation is not permission to guess what was omitted.

Keep historical detail in dated checkpoints and evidence files. Keep project memory concise: accepted decisions, durable facts, sources, and conditions that would require rechecking them. A useful checkpoint points to the next action; it does not repeat the entire conversation. See Planning and memory.

An old successful check proves the condition tested at that time and scope. Changing code, infrastructure, accounts, permissions, or the environment may require new evidence. Recheck what changed rather than rerunning every past check automatically or trusting all old results indefinitely.

Coordinate writers and resources

Agent 0 owns the canonical ledger and integration. Workers have explicit file scopes and return concise reports. Assign one owner for a shared compiler, database, browser session, installer, or deployment target. Track active job handles in coordination notes and follow them to a terminal result before starting conflicting replacement work.

The local CLI lock protects ledger writes within one checkout. It does not coordinate independent Git worktrees, cloud-synchronized copies, application files, or remote processes. Agree on a single authoritative writer and a merge or handoff procedure. For Drive, follow Google Drive setup and resolve synchronization conflicts before allowing another writer.

Recover deliberately

On interruption, preserve local changes and inspect the last checkpoint, canonical state, current revision, and retained live job handles. A timeout means observation stopped; it does not prove the job failed or was cancelled. Record which actions completed and which remain uncertain before retrying.

When blocked, record the actual missing dependency, permission, input, or external-state change. Retry when there is a reason the outcome may differ. If the environment cannot continue, save a handoff and state what is required next. A plain .SYSTEMX folder does not schedule future turns or keep an assistant running after its session ends.

Understand current scale limits

WORK/TASKS.json is loaded as a whole. Updates write the ledger and regenerate its status views. Large histories increase file size, validation work, merge cost, and update time even when the context packet remains bounded. Markdown checkpoints are separate files, but moving them does not shrink task history. The optional message schema is a record format, not a transport or event store.

Before relying on a very large backlog, test a sanitized copy at representative size in your own filesystem and sync environment. Measure validation and update time, memory use, generated-view size, and conflict recovery. Keep recoverable backups. Report the environment and results with any scale claim.

Do not delete completed task records to make the ledger smaller: current references, dependencies, and history may depend on them. There is no built-in automatic ledger archival or database migration command. Any future archival, indexing, or event-store adapter needs a versioned migration that preserves IDs, references, evidence, and recovery. See Technical Guide.

Define the finish line

A project is done when its agreed acceptance criteria have evidence and review, remaining limitations are disclosed, and any required delivery or operational checks have succeeded. A blank TODO view alone cannot prove that: tasks may be blocked, awaiting review, cancelled, or never recorded.

Record the accepted milestone, the evidence scope, outstanding obligations, and ownership of later maintenance. External actions still require the project's actual authority. Use Evidence and acceptance for the difference between source checks, deployed behavior, and ongoing operation.

Measure progress that matters

Track accepted outcomes, repeated work, reopened tasks, unplanned scope changes, context size, tool calls, elapsed time, and usage where available. Include the cost of keeping records and coordinating agents. Smaller packets and more workers only help when the resulting work meets the same acceptance criteria. See Tokens, cost, and time.

A shared-brain workflow with a stopping rule

The founder's “simulated AGI brain” metaphor refers to persistent shared context and coordinated specialized roles. The files do not create general intelligence or guarantee improvement each turn. Useful knowledge grows only when original evidence and corrections are reviewed, retained, and retrieved in the right scope. Follow the turn protocol: read relevant changes, perform a bounded action, record time and proof, update canonical tasks, review at a meaningful boundary, and save the next step or stop.

Keep planning depth proportional to the work

Optional ROOT planning and task delta organizes milestones, waves, phases, groups, tasks, subtasks, and concrete actions without requiring every level or fixed counts. Expand the next useful segment rather than multiplying a speculative tree. RTask/STask preserve request provenance; Agent X events preserve observations; neither becomes a second task-status system. ROOT delta makes stale, unavailable, unverified, or divergent harness/bot observations explicit. An unchanged mismatch is a checkpoint/blocker to resolve, not a reason to run every agent or review again.