This directory is the canonical technical record for K1412 Agent. The public documentation portal at https://agent.k1412.top/doc/ is a curated rendering of the same design. When behavior, infrastructure, or an experiment changes, update the relevant Markdown document and the portal snapshot in the same commit.

Start here

Document	Audience	What it answers
Architecture	Everyone	What runs where, and why are the boundaries drawn this way?
Agent loop	Agent researchers and backend engineers	How do context, tools, scheduling, evidence, memory, and child Agents work?
Experiment system	Agent researchers	How do we change the loop without losing comparability or production safety?
Project history	Maintainers	Which product and architecture decisions have already been made?
Open WebUI integration	Frontend and platform engineers	What belongs to Open WebUI, and what remains K1412-owned?
Security model	Security and platform engineers	How are users, credentials, workspaces, and Docker separated?
Infrastructure map	Operators	Which services are shared infrastructure and which are Agent core?
Development and verification	Contributors	How do I run, test, and safely change the system?
Operations runbook	Operators	How is production built, deployed, verified, backed up, and migrated?

Current product contract

There is one user-facing mode: the K1412 Agent loop. The earlier Chat/Work split was removed deliberately.
Open WebUI owns accounts, sessions, approval, conversation storage, and the chat shell. K1412 owns Agent behavior.
Four server-defined model choices are exposed: Luna, Terra, Sol, and DeepSeek V4 Pro. Model identity and thinking capability are displayed separately.
Every Open WebUI user receives an isolated Docker container, network, and persistent volume on the dedicated physical execution host.
Generated files can be browsed and downloaded through the authenticated Web UI. Internal dependency directories are hidden.
Provider credentials, internal prompts, Docker access, SSH configuration, and tool-service credentials are never browser-configurable.

What is experimental

The stable platform boundary is authentication, user/workspace isolation, durable storage, and the public OpenAI-compatible Runtime API. The intended experimental surface is:

context selection and compaction;
memory retrieval and lifecycle;
tool descriptions, normalization, and routing;
parallel scheduling and mutation serialization;
child-Agent delegation policy;
evidence and completion gates;
recovery prompts and retry policy;
model routing and per-tier budgets.

Every experiment should be versioned in run events and evaluated against a fixed task set before production rollout. See experiments.md.