Temporality Roadmap

#Status: October 2026

#Done (P0)

• Kernel P0 — failure/reconciliation, duplicate mitigation, cost accounting, quotas, secrets, runbook
• Live MCP E2E — test-mcp in image, sandbox volume, KERNEL_MCP_TEST_ROOT, approval flow
• Journal endpoints — state-at-T, diff, activation chain, run state-at-T, compare runs
• Workspace refactor — agents top-level, providers CRUD, users CRUD with DB tokens
• Experience Priming — unified engine observation.FindHints (individual ranking, lifecycle gating, budgets 600/120/8, dedup/diversity, skill-context novelty B5, outcome usefulness B4, issued suppression), benchmark corpus in CI (see docs/plan-priming-relevance.md)
• Carbon Design System — full integration, dark theme, proper input styles
• Workspace chat — SSE streaming, conversation history, Markdown rendering, agent selector on new chat
• Operations page — human-readable tool display, verdict buttons, pending badge
• Runs trace — rich event timeline with arguments/output, color-coded icons
• Memory Lens filters — strength, recency, activated, cross-scope, terminal state, presets
• Experience Timeline — SVG, scopes, lifecycle, zoom, semantic zoom, detail panel
• Pending badges — Operations (uncertain ops) and Runs (approval requests) on nav bar
• Sandbox network — agent network_access wired to Docker --network=bridge
• Read-only tools — read_file/search/grep no longer flagged as uncertain operations
• Task reuse — follow-up chat messages reuse same task, not creating new ones
• Tool arguments in traces — tool.started has arguments, tool.completed has output
• Cost accounting v1 — model prices, per-call costs (per-run/project aggregation pending)
• Trace informativeness pass — delegation/knowledge/hint/plan rows resolve propositions and agent ids instead of guids; delegate tool previews target agent + prompt gist; MCP completions show result size; agent summaries show the answer
• Live model-call progress in Runs — in-flight «Вызов модели» row shows elapsed time, ~tokens, tok/s and stream liveness (alive/stalled/waiting first token) from the ephemeral token SSE at 1Hz
• First-run bootstrap — fresh installs configure themselves in the wizard: migration list fix (intake_enabled), gate hardening (internal loopback token never enables auth; first created user does), auto-generated secret master key persisted to workspace_setting with env override, runtime-swappable sandbox runner with GET /v1/setup/status + POST /v1/setup/sandbox/build (digest-pinned embedded Dockerfile, no restart needed), onboarding now walks project → admin user → provider (secret-backed key) → agent → sandbox build → summary, and hides the main navigation until the first project exists

#Done (Platform wave, Sept–Oct 2026)

• Triggers — schedule (cron), webhook (HTTP endpoint), event listeners; agent tools list/create/update/delete triggers
• Approvals in chat — approval step for consequential tools, approval badge on Runs tab
• Run cancel — POST /runs/{id}/cancel + Stop button in chat
• Thinking display — reasoning stream shown compactly in chat widget
• i18n — full EN/RU localization, auto-detect browser language
• Light/dark themes — OS auto-detect via prefers-color-scheme, persisted choice
• Onboarding wizard — welcome → project → provider → agent → done, shown on empty workspace
• Project-centric permissions — allowed_users on projects, per-user project visibility, admin bypass
• Auth gate — clean token-entry screen for logged-out users
• Design system — forest/teal/amber identity per DESIGN.md, favicons, consistent dialogs

#Done (Access & agents wave, Oct 2026)

• Agent definitions & prompt compiler — structured definition instead of free-form prompts, immutable versions, meaning-first UI, NL agent builder, regenerate with diff, evolution tab (see docs/plan-evaluable-agent.md — complete)
• MCP server registry — workspace MCP servers (stdio / SSE / Streamable HTTP), agent assignment, per-agent tools panel incl. MCP tools, connection test (POST /v1/workspace/mcp-servers/discover + «Discover tools» in the form)
• Conversation branching — fork a conversation from any point
• Auto run titles — short run names generated by a lightweight model call (kernel/agent/runtitle.go)
• Delegation & plans — delegate tool (parallel subagents) + plan tool (DAG across agents with predicates); delegation tree and plan graph in Runs and chat (docs/agent-delegation.md)
• Knowledge extraction — observations/claims extracted from trajectories after run completion, confirmation flow, remember linkage (docs/knowledge-extraction.md)
• Org structure & access model — org tree with materialized paths, resource binding + effective visibility, project↔units many-to-many, explicit membership, node roles, run authorization, execution identities, unit-scoped triggers, human_request entity with recipient resolution, org policies with restrictive merge — waves A–F
• Org wave G: migration & cleanup — old/new access-model divergence report (scripts/access_divergence.sh), dropped the legacy allowed_users / workspace_user.projects columns and their CRUD round-trips, access-model runbook section (docs/runbook.md §11)
• Skills CLI — temporality skill list/inspect/validate/history/executions/memory against the kernel API (cmd/temporality/)
• Org UI tails — roles-on-nodes editor and execution identities management in Organization tab
• Experiment 9 corpus — comprehension acceptance fixture debugger/src/fixtures/experiment9-webconfig.json + fold assertions (docs/experiment-9-corpus.md)
• Sandbox security matrix — matrix doc + args/timeout/credentials/network tests incl. live egress check (docs/sandbox-security-matrix.md)
• Knowledge reinforcement live check — scenario B of docs/knowledge-evolution.md §11 verified live: deterministic auto/ execution observation proposed in run 2, confirmed by execution-reverification.v1 in run 3 (scripts/audit_knowledge_live.py → reinforced: 1)

#Done (Experience & platform wave, Oct 2026)

• Web research — three phases shipped: web_fetch (readability → markdown, SSRF guards), web_search over self-hosted SearXNG with rate limiting, vision (view_image / fetch_image, images as content blocks) and browser — a headless browser over a CDP contract (Lightpanda by default) for JS-rendered pages (docs/web-research.md)
• Agent quality loop — eval-gated apply of evolution proposals (fresh green run required, suite/base staleness checks, writer override with justification is audited), golden cases with stale_after, LLM judge with calibration endpoints and verdict/judge agreement, per-version quality dashboard (docs/agent-quality-loop.md)
• Artifact registry — reference documents (regulations, instructions, checklists) that skill manifests point at without inlining into prompts: CRUD + org visibility, artifact_search / artifact_read chunked agent reads with artifact.read auditing, kernel-proxied url provider with a TTL cache, registry UI with "used by N skills" badges (docs/artifact-registry.md)
• Sagas — explicitly registered long-running efforts: saga_register / saga_attach / saga_list agent tools, task-level binding (chat follow-ups and delegated children join automatically), events-only storage (saga.registered / saga.attached), cross-agent takeover via saga_attach (docs/sagas.md)
• Budget observability — task budget (GET /v1/agent/cost/task: every run of a task with chat follow-ups and the delegation tree) and project budget (GET /v1/agent/cost/project-budget: totals plus per-saga/per-task rows with time, tokens, cost and approval budget) surfaced on the project overview page
• Activity scoping rethink — runs, operations, triggers and questions are global listings: the project is a filter/attribution, not a partition; the hidden-run and dead-end badge classes of bugs are gone (docs/activity-scoping.md)
• Knowledge listing — searchable, faceted, paginated knowledge page with compact bitemporal filters and presets; inline doubt/invalidation actions from the run trace
• Run detail tabs — trace / trajectory / budget as tabs under the run title; long-run chat reconnect via journal tail (?tail=1) instead of full replay
• Mattermost inbound over WebSocket — DMs included, outgoing webhooks and OUTGOING_TOKEN removed (see Channel driver layer)
• Webhook delivery visibility — trigger deliveries surfaced in the UI
• Model gateway resilience — stream idle/no-progress watchdogs, first-token timeout with an adaptive prefill budget and a manual nudge endpoint; runs survive host sleep

#P0 — Living Skills MVP

Source spec: docs/living-skills.md (§43 MVP).

• Skill package — SKILL.md + skill.yaml manifest; legacy loading (manifest inferred from SKILL.md, fields marked inferred)
• Skill registry — project-scoped storage, immutable versions, CRUD API
• Contract validation — manifest schema, capabilities, tools, runtime requirements checked before use
• Prompt injection — compact skill digests in agent system prompt with token budget
• Agent tools — skill_search, skill_inspect, skill_validate, skill_history, skill_executions, skill_memory, skill_propose (draft via skill builder, saved as 0.x pending human review)
• Execution linkage — runs record skill versions used; executions listed per skill
• Memory linkage — remember accepts skill_id/capability; per-skill memory view
• Skills UI — tab with overview/contract/executions/memory/versions; skill selection on agent form
• CLI — temporality skill list/inspect/validate/history/executions/memory

Not in MVP: agent-driven skill mutation beyond 0.x drafts (full evolution workflow), evaluation engine, marketplace, policy engine (Phase 2).

#Phase 2 (after MVP)

• Evolution proposals — draft versions carry the proposal anatomy (observed problem / proposed change / expected effect + evidence & knowledge provenance); apply/reject are the human approval workflow (skill.applied / skill.rejected journal events); skill_diff, skill_evaluate agent tools; CLI apply/reject/diff
• Skill diff / rollback — apply of an older active version is the rollback path (history immutable); diff in Skills UI and CLI. Snapshots as a separate artifact remain open (versions already are immutable snapshots)
• Evaluations — per-skill suites (cases with must/must-not-contain patterns), synchronous runner recording run history, skill.evaluation.completed events, Skills UI «Оценки» tab, CLI evals / eval-run
• Contextual memory retrieval per skill/capability
• Evolution analytics
• Note: skill_apply / skill_rollback stay human-only by design (docs/living-skills.md §26: agents observe/propose/evaluate, people approve) — an agent requests approval via request_approval

#P0 — MCP server registry

Status: shipped.

• MCP servers tab — configure servers per transport: stdio, SSE, Streamable HTTP
• Agent MCP assignment — select configured servers on agent form
• Agent tools panel — per-agent tool availability toggles, including MCP-provided tools
• Connection test — validate server config before save (POST /v1/workspace/mcp-servers/discover, «Discover tools» button with tool checklist)

#P0 — Evaluable Agent (agent definition & prompt compiler)

Source spec: docs/evaluable-agent.md, work plan: docs/plan-evaluable-agent.md. Status: Phase 1 complete — all original plan items done (2026-10-10 revision synced the plan with the current spec: builtin templates are never auto-created, QA template added, delegation capability and org-unit visibility recorded). Phase 2 complete — see below.

• Agent definition — structured definition JSONB (purpose, capabilities, constraints, completion) instead of free-form system prompt; immutable workspace_agent_version per change
• Prompt compiler — deterministic compile from semantic components (base evidence contract + role + constraints + completion + env policy); no tool/skill duplication, no step-by-step instructions
• Capability enforcement — toggles actually restrict (modify_files → read-only + no write tools, run_commands, network, skills, knowledge)
• Agent builder — NL description → structured draft (pattern: skill builder), wizard with provenance badges and questions
• Regenerate with diff — field-level diff vs current definition, manual edits highlighted, accept/cancel
• Meaning-first UI — card shows Purpose/Can/Cannot/Before-done summary; compiled prompt as a secondary view with optional manual override
• Built-in agent templates — Coder/Reviewer/Researcher/QA/DevOps shipped as gallery templates, never auto-created; editable via the same UI
• Evolution tab — version timeline + per-version run stats (runs link agent_version)

#Phase 2 — evaluations & evolution

Status: complete (except the optional eval CLI tail).

• Agent evaluations — per-agent suites checked against the compiled prompt of a pinned definition version; synchronous runner, run history, agent.evaluation.completed events, «Оценки» section in the Evolution tab (mirror of skill evaluations)
• Evolution analytics — per-version eval pass rate + run outcomes (avg turns) with regression highlight (pass-rate drop vs previous version on an unchanged suite)
• Evolution proposals — proposal anatomy (observed problem / proposed change / expected effect + evidence), agent_propose tool, workspace_agent_proposal storage, agent.definition.proposed/applied/rejected events, human-only apply through the regular version path; capabilities are never proposable
• Agent eval CLI — temporality agent evals / eval-run (optional tail of stage 8)
• Note: agents propose, people apply — mirror of docs/living-skills.md §26

#P1 — Make experience understandable

• Activation chain UI — click knowledge → see where it arose, where recalled, where injected, what decision followed, what actions, what outcome, where validated/invalidated/superseded. Distinguish: reused/validated, failed, invalidated, superseded, resurrected.
• Semantic zoom — Knowledge → Episode → Event. Episode = turn / tool call / observation / formation / validation / invalidation / reuse. Transition from "event log" to "experience episodes".
• Forensic View — why did this experience appear? which evidence? which run/action/outcome?
• Experience lineage — K82 → K73 supersession chain visible on timeline
• Shareable investigation URL — backend done, frontend polish needed. Lens, filters, zoom, selected entity all in URL.
• Investigation flows — "why did agent do this?", "why did knowledge disappear?", "why do two runs differ?", "what does the team know?"
• Experiment 9 corpus — validate human understanding of experience evolution through UI. Scenarios: competing hypotheses, repeated confirmation, contradiction, resurrection, stale knowledge, supersession, different scopes. Delivered as fixture + fold assertions (docs/experiment-9-corpus.md, debugger/src/fixtures/experiment9-webconfig.json); live operator session against the UI still pending.

#P1 — Platform usability

• State-at-T as product feature — not just an API endpoint. "What did the system know when this decision was made?" needs a proper UI accessible from timeline/trace.
• Streaming improvements — live model tokens (answer + reasoning) now stream to the chat through an ephemeral in-memory bus (TokenBus) fed by StreamComplete in CallModel (blocking Complete remains the fallback), exposed as GET /v1/workspace/runs/{id}/tokens SSE; the journal stays turn-level (a token is not a durable fact). Single-process only — multi-node workers need a real transport (Redis/NATS), noted as the scaling boundary.
• Agent templates — pre-configured agents for common tasks (coder, reviewer, researcher)
• Project settings — per-project defaults for agent, model, sandbox
• Bulk operations — select multiple runs/operations for batch actions

#P1 — Sandbox security matrix

Automated security acceptance (not a sandbox platform).

Existing coverage in kernel/sandbox/docker_test.go:

• ../ workspace escape — blocked (symlink escape test)
• Docker socket / privileged — inaccessible (--cap-drop=ALL, no --privileged, image digest pinned)
• Memory/CPU/PIDs — limited (args enforced in test)
• Output — bounded (limited buffer truncation test)
• Read-only workspace for reviewer/qa roles — enforced via args
• Network egress — --network=none default / bridge only with granted access (args test + live check: none → curl exit 6, bridge → HTTP 200)
• Credentials — only HOME/TMPDIR cross the boundary, nothing from the host env (args test)
• Timeout — request context kills the run, container force-removed (test with fake docker)
• /scratch — isolated between executions by construction (fresh container + private tmpfs per command)
• Expected-vs-actual matrix doc with explicitly accepted risks (docs/sandbox-security-matrix.md)

#P1 — Before inviting first users (Minimum Usable Experience)

#Setup

• project
• agent
• system prompt
• model
• skill — via Living Skills MVP (skills tab, agent skill selection)
• MCP — via MCP server registry (incl. connection test)
• sandbox

#Execution

• task
• run
• streaming/status
• tool execution
• approval
• result
• run cancel

#Observation

• run timeline
• tool calls with arguments/output
• model calls
• MCP provenance
• operations
• uncertain operations

#Experience

• knowledge
• activation chain
• state-at-T
• replay
• diff

#Iteration

• change prompt
• re-run
• compare runs
• change skill — skill versions are immutable; edit a skill and bump the version

If this exists, we can invite a small team and stop relying only on fixtures.

#Open — org structure deferred tails

• External users — user_type / expires_at on workspace users
• Provider credentials — api_key_ref resolves through the secret store: secret://name[#key] refs decrypt at the routing boundary (resolveProviderAPIKey), UPPER_SNAKE names read the process env, legacy literals still pass through; the model-config answer carries plaintext keys only to the kernel's service principal — human callers get api_key_ref; keyless providers (empty key) route fine now

#P1 — Channel driver layer

Source spec: docs/channels.md.

• Phase 0 — extract the layer — ChannelDriver contract (spec/capabilities, settings schema, SendText/SendFile, pull Poller); matrix/telegram/slack/generic-webhook became drivers (kernel/agent/driver_*.go, one registration line); settings → JSONB payload + KERNEL_CHANNEL__* env aliases with legacy names kept, generic admin form from the driver schema; matrixInboundLoop → generic channelInboundLoop over every driver with a Poller, channel-neutral MatchChannelReplies, cursors + settings fingerprint persisted. Dedup table and sender-identity verification land with the intake pipeline (phase 1, docs/inbound-messages.md). Push Webhook drivers and interactive options remain future work.
• Telegram inbound driver — two-way telegram (kernel/agent/driver_telegram_inbound.go): getUpdates poller with a persisted offset cursor, private-chat identity (chat.id = from.id), document/photo attachments via getFile; zero edits outside the driver file beyond capabilities/settings declaration
• New inbound channels as drivers — push model landed in the driver contract: Webhook() (Route/VerifyRequest/Parse/Respond) next to Poller(), and one shared receiver (channelWebhookReceiver) feeds verified pushes into the same pipeline as polls (dedup → reply matching → intake, serialized per channel). Mattermost driver: REST v4 posts + self-hosted outgoing webhooks (form-encoded, shared-token verification, trigger-word strip, base_url setting); Slack bot driver: Events API with v0 HMAC signatures + 5-min freshness window, url_verification handshake, threads carried as ReplyTo, bot/subtype events skipped, error envelopes (ok:false) surfaced from every Web API call. In-memory retry fence for webhook replays (at-least-once preserved). Interactivity stays a separate roadmap item
• Mattermost inbound moved to WebSocket — mattermostPoller (kernel/agent/driver_mattermost_inbound.go): one WS connection per 25s poll window, authentication challenge with the same base_url+token pair, posted events parsed (post is a JSON-encoded string inside the payload), DMs included — which outgoing webhooks cannot serve; cursor = last seen create_at (ms), own posts excluded via users/me self. Outgoing-webhook adapter and the /v1/channels/mattermost/hooks route removed: deployments should delete the server-side webhook, the poller starts working with the credentials already configured
• Interactivity — options as buttons where the channel supports them (Telegram inline keyboards, Slack blocks), text fallback everywhere

#P1 — Inbound messages (channel-initiated tasks)

Source spec: docs/inbound-messages.md.

• Intake MVP (Matrix) — workspace_inbound_message + dedup by event id,, sender identification (closed world: room = registered address, sender = registered identity), system intake project with a create-if-absent intake agent (KERNEL_INTAKE_ENABLED kill switch), intake tools search_projects / search_org_units / intake_decide / start_task over internal /v1/intake/* endpoints (identity from the run, authorization as the sender's principal, deterministic task id per message), events intake.received|rejected|classified|routed, «Входящие» page with the state machine and run links
• Org unit head & team requests — org_unit.head_user_id + effective head (bottom-up), escalate_for prefers the head, org: recipients fan out to all active members (first answer wins), head field in the org tree UI, run_status / cancel_run for status queries and cancellation from the channel
• Dialog & Telegram — amendments: start_task accepts amend_run_id (run from the sender's own routed messages, 422 on project mismatch), follow-up run on the same task with prior outcome in the prompt and amends_run in the ExecContext; Telegram became a two-way driver — telegramPoller (getUpdates long-poll 25s, persisted offset cursor = max update_id+1, api_base setting for self-hosted Bot API, getFile downloads ≤100MB, photos take the largest size), capabilities TwoWay+FilesIn; initiative attachments land in {sandbox}/inbound/{hash}/ staging, start_task copies them into the project inbox and appends /workspace/inbox/... paths to the run prompt; intake prompt upgraded in place via prompt_version label (admin edits preserved)
• Intake policy — per-project opt-in workspace_project.intake_enabled (default off — only projects with already-routed messages were backfilled to true), start_task refuses routing with 422 until an admin flips it; org policy intake_mode = deny is a subtree veto a child cannot loosen (folded into EffectivePolicy over sender's unit + project units, 403); sender rate limit KERNEL_INTAKE_MAX_PER_HOUR (default 10, 0 = off) rejects with intake.rejected reason rate_limited + room notice + audit instead of an intake run; retention KERNEL_INTAKE_RETENTION_DAYS (default 30, 0 = forever) scrubs bodies/attachments on the inbound list sweep, the row survives as the audit link with retired_at marked in the UI; GET /v1/intake/audit?sender= chains message → intake run → task run without bodies; UI: intake toggle in the project form, intake mode in the policy editor

#P2 — Advanced

• Read-after-write probes — operation → observable trace → probe → hint to operator. Probe gives a hint, does NOT automatically issue authoritative verdict. Первая реализация удалена как нерабочая по предпосылкам; вернуться к идее — с дизайном от реальной формы аргументов и внешних следов.
• Cost accounting v2 — cost per run / per project / per task / per saga ✅ (в Done выше); остаются org-уровневые токен-квоты
• Memory population overview — active/stale/invalidated counts over time
• Cross-project knowledge — knowledge that spans multiple projects
• Embeddings infrastructure — if lexical clustering proves insufficient
• Graph-based experience relations — when timeline is not enough

#NOT doing (until proven necessary)

• Universal graph clustering
• Topic modeling
• Graph database
• Complex automatic clustering
• New runtime
• Complex visual editor
• Generic event viewer / second debugger
• Separate scheduler
• Complex model gateway (until second provider/fallback/routing needed)
• Complex tenant model (until multiple org structures exist)
• Full sandbox platform
• Automatic agent-loop-to-workflow replacement

Return criterion: a concrete real usage scenario that cannot be satisfied by current architecture.

#Deferred infrastructure

#Architecture

Temporal          — durable execution and orchestration
Agent Harness     — agent execution semantics
Temporality       — experience and memory
Enterprise CP     — identity, tenants, RBAC, secrets, quotas, policies
Infrastructure    — compute, containers, DB, network

#Продуктовое направление

Temporality is at a transition point:

Phase 2: "We proved the model is correct"
    ↓
Next: "We made a system that people can use"
    ↓
Goal: "People use it to understand and improve agent experience"

The immediate goal is NOT to close all Phase 2 remnants.

The immediate goal:

Collect a minimum end-to-end working loop where a real person runs a real agent and Temporality turns the resulting experience into an investigable temporal picture.

Living Skills extend this loop: the skill a person installs becomes an observable, versioned capability whose usage produces memory and evidence.

After that, every experiment must be simultaneously:

• acceptance corpus
• real working scenario
• source of product requirements

This way Temporality won't drift into "yet another debugger" or "yet another agent runtime".