Own human intent through program delivery and add live Proof operations

.gitignore

@@ -217,6 +217,7 @@ marimo/_static/
 marimo/_lsp/
 __marimo__/
 .agent_result.md
+.agent_actions.json
 PLANNING_RESEARCH.md
 PLANNING_SIGNALS.md
 PRODUCT_INSPECTION.md

README.md

@@ -6,9 +6,28 @@
 [![GitHub issues](https://img.shields.io/github/issues/kai-linux/agent-os)](https://github.com/kai-linux/agent-os/issues)
 [![License](https://img.shields.io/github/license/kai-linux/agent-os)](LICENSE)
 
-**An autonomous-first software organization for supervised rollout: agents handle routine delivery loops, while humans stay in governance, review, and escalation paths.**
+**Persistent delivery of human intent: tasks, projects and programs with retained scope, bounded execution, explicit human handoffs and evidence-based completion.**
 
-You give it a backlog. It ships product.
+GitHub is the workspace and planning interface, not the definition of success.
+Coding workers, non-coding artifacts and registered action adapters operate under
+the same goal ownership. Capabilities and authority remain explicit boundaries.
+
+## Live Operations
+
+The private [Proof](https://github.com/kai-linux/proof) dashboard goes beyond the
+Kanban: verified outcomes, program/project ownership, live worker leases, waiting
+conditions, delivery times, deadline performance, retries, cost coverage and
+notification failures. Worker claims and unverified historical data remain separate.
+
+```bash
+python -m orchestrator.dashboard.server --port 8765
+# Private host-local dashboard: http://127.0.0.1:8765
+```
+
+See [persistent delivery and operations](docs/delivery.md) for contracts, controls,
+authority boundaries, migration, private access and deployment. The default planning
+policy manages accepted commitments rather than generating speculative growth work.
+This is not a claim of unrestricted autonomy or a completed non-coding production pilot.
 
 **Public proof — everything is auditable:**
 [Reliability dashboard](docs/reliability/README.md) · [Case study](docs/case-study-agent-os.md) · [Live discussion](https://github.com/kai-linux/agent-os/discussions/167)
@@ -23,13 +42,14 @@ Live Kanban Board: https://github.com/users/kai-linux/projects/6/views/1
 
 <p align="center"><em>Real execution: Issue <a href="https://github.com/kai-linux/agent-os/issues/115">#115</a> → agent dispatched → code written → tests pass → <a href="https://github.com/kai-linux/agent-os/pull/122">PR #122</a> merged → issue closed. The happy path can complete without manual coding, but new repos should still start in supervised mode.</em></p>
 
-### Agent Performance - rolling 14 days
+### Historical Agent Performance - April 21, 2026 Snapshot
 
 | Success rate | Mean completion | Escalation rate | Tasks executed |
 |:---:|:---:|:---:|:---:|
 | **69%** (61/88) | **0.1h** | **11%** (10/88) | **88** |
 
 Current pool: OMP (GLM-5.2) · Claude · Codex. Gemini and DeepSeek were retired from rotation after quality review. Metrics above are from the public reliability dashboard updated on 2026-04-21.
+These are historical task-level reports, not the live verified-goal success rate.
 [Full reliability dashboard →](docs/reliability/README.md) · [Multi-agent case study →](docs/case-study-agent-os.md)
 
 ---
@@ -68,9 +88,11 @@ The best adoption story is not "trust us blindly." It is "run a cheap, auditable
 
 ## Goal
 
-Make Agent OS the most credible autonomous software organization for technical founders and solo builders: a system that can reliably turn backlog input into useful shipped work, improve itself from operational evidence, and earn trust through visible results. Prioritize work that increases adoption, reliability, evidence quality, and operator confidence over work that only creates attention.
-
-> **This README was written by an agent. The CI pipeline was built by an agent. The backlog groomer that generates improvement tickets was written by an agent dispatched from a ticket that was generated by the log analyzer. It's turtles all the way down.**
+Carry accepted human intent from scope to verified delivery, including entire
+projects and programs. Retain ownership through dependencies, waits and failures;
+ask for a specific human decision when needed; never substitute activity, a plan,
+a commit or a model's confidence for the requested outcome. Improvement should
+address reproduced failures and measured outcomes, not manufacture more backlog.
 
 ---
 
@@ -88,6 +110,12 @@ Agent OS solves coordination so agents can do more of the routine delivery work
 
 ## The Loop
 
+For managed work, the durable delivery controller surrounds this existing coding
+execution path. Parent goals remain open after decomposition, prepared PRs wait
+for integration/acceptance, and notifications retry independently. The planner
+and groomer no longer generate new growth scope by default. See
+[the delivery lifecycle](docs/delivery.md) for non-coding checks and control rules.
+
 <pre lang="text">
             GitHub Issue (Backlog)
                     │

STRATEGY.md

@@ -4,20 +4,24 @@
 
 ## Product Vision
 
-Agent OS should win by being the most credible autonomous software
-organization for technical founders and solo builders.
+Agent-OS should persistently manage human intent from agreed scope to verified
+delivery, including complete projects and programs across coding and non-coding
+work. GitHub is a planning interface; it is not the boundary of execution.
 
-The strategic target is GitHub stars as the primary proxy for trusted adoption.
-Stars measure whether technical builders find Agent OS credible enough to
-bookmark. Growing stars requires: clear proof the system works, fast activation,
-a compelling demo, and a README that sells in 10 seconds.
+The mandate is scoped delivery, not autonomous backlog growth. Preserve the
+original intent, own the full dependency graph, keep explicit budgets and
+authority, and verify outcomes at their intended targets. Report uncertainty and
+specific human decisions without discarding completed work or repeating side
+effects. Acceptance of child work does not establish program acceptance.
 
-Sprint selection should balance:
+Measure verified delivery, elapsed time, retries, human intervention, resource
+coverage and operational reliability. Missing evidence is not success; unknown
+provider spending is not zero. GitHub stars and repository activity are not
+proxies for fulfillment of a person's intent.
 
-- adoption and credibility work (demos, README, quickstart, public proof) — at least 40% of sprint capacity
-- execution reliability and recovery quality — as needed to maintain trust
-- evidence-driven planning including external adoption metrics (stars, forks, traffic)
-- structural fixes that prevent the system from only optimizing its own plumbing
+The default planning policy is `scoped_delivery`. The earlier growth planner is
+available only through explicit `planning_policy: legacy_growth` configuration.
+The sprint history below is historical context, not the current mandate.
 
 ## Current Focus Areas
 
@@ -634,4 +638,3 @@ PRs merged:
 
 **Plan:**
 - [prio:high] Bootstrap STRATEGY.md from repo state: This week should establish product foundations, and an auto-generated initial strategy closes the biggest planning gap by giving the strategic planner a durable source of direction instead of operating without a strategy document.
-

bin/run_delivery_dashboard.sh

@@ -0,0 +1,8 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Read-only monitoring remains available while execution is disabled.
+export AGENT_OS_IGNORE_DISABLED=1
+. "$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)/common_env.sh"
+cd "$ROOT"
+exec "$ROOT/.venv/bin/python3" -m orchestrator.dashboard.server "$@"

contrib/systemd/agent-os-dashboard.service

@@ -0,0 +1,16 @@
+[Unit]
+Description=Agent-OS private delivery operations dashboard
+After=network.target
+
+[Service]
+Type=simple
+WorkingDirectory=%h/agent-os
+ExecStart=/bin/bash %h/agent-os/bin/run_delivery_dashboard.sh
+Restart=on-failure
+RestartSec=5
+UMask=0077
+NoNewPrivileges=true
+PrivateTmp=true
+
+[Install]
+WantedBy=default.target

docs/delivery.md

@@ -0,0 +1,231 @@
+# Persistent Delivery And Operations
+
+Agent-OS now has a durable delivery controller for newly dispatched GitHub work.
+It owns the original human request across attempts, child work, waits and restarts.
+GitHub Projects remains the planning interface; the private Proof dashboard shows
+operational health and evidence-based KPIs. Neither a model's result file nor an
+issue being closed is sufficient acceptance evidence.
+
+## The Operating Contract
+
+Move a trusted issue to **Ready** in a configured project as before. The dispatcher
+retains its title/body verbatim and records any model interpretation separately.
+New work receives a stable `g-...` identity and a revision in
+`runtime/delivery/state.sqlite3`. Back up this directory with the private runtime,
+including SQLite's WAL when active, or use SQLite's backup API. Do not commit it.
+
+Simple coding issues default to an explicitly linked PR merged to the configured
+base branch. This proves integration, not semantic correctness or deployment.
+Add checks for the actual destination when a merge alone is insufficient.
+Non-coding work without checks needs explicit human acceptance, not a fake diff.
+
+Optional issue section:
+
+````markdown
+## Delivery Contract
+```yaml
+kind: program
+scope: Deliver the launch, including the public recording and supporting site.
+out_of_scope: Paid advertising and new account creation.
+targets:
+  - owner/workspace
+  - owner/website
+  - https://example.org/launch
+max_attempts: 24
+max_parallel: 2
+budget_usd: 30
+deadline: 2026-10-01T16:00:00Z
+checks:
+  - id: published-launch
+    type: url
+    url: https://example.org/launch
+    status: 200
+    contains: ["Watch the walkthrough"]
+  - id: final-acceptance
+    type: human
+risks:
+  - Publication needs delegated account access.
+```
+````
+
+Budgeted goals require `delivery_attempt_reservation_usd` in operator config.
+Attempts, concurrent slots and reservations count across the entire parent tree,
+including retries and revisions; switching providers does not reset limits.
+Unknown actual cost retains its reservation. This is an admission-control budget,
+not a guarantee against a provider charging above a reservation. Use provider-side
+spend caps for an absolute financial ceiling. Actual charges remain unknown until
+observed; the dashboard does not invent them from text length.
+
+## Programs And Projects
+
+Use `kind: program`, `project` or `milestone`, or a corresponding `task:program`
+label. The decomposer proposes 2-20 work packages per level, with stable keys and
+dependencies. Larger programs need project-level decomposition rather than
+silently dropping packages. Cross-repository work is limited to configured
+workspaces explicitly named in the parent targets.
+
+The controller persists the scope baseline before creating issues, recognizes
+its own child markers after interruption, and dispatches dependency-ready work.
+Each child retains a parent and parent revision. Completing every child still
+does not satisfy the parent's own combined acceptance checks. No parent issue
+is closed just because decomposition succeeded.
+
+Declare existing dependencies with `depends_on: [owner/repo#123]` and an existing
+parent with `parent: owner/repo#100` in the contract. Those goals must already be
+registered. Cycles, including implicit parent/child completion dependencies, are
+rejected. A parent's paused state or unmet prerequisite also blocks its children.
+
+## Evidence And Non-Coding Actions
+
+Available checks are `merged_pr`, `file`, `url`, `configured_command` and `human`.
+File checks accept workspace-relative `path`, `min_bytes`, `contains` and `sha256`.
+Verified small artifacts are archived privately before worktree cleanup. Paths
+cannot escape the workspace. URL checks need an exact declared target, reject
+private network addresses and redirects, and support status/content/hash checks.
+Observations are limited to 2 MiB; use a dedicated verifier for video/media.
+
+A `configured_command` check contains only `id`, `type` and an operator-configured
+`name`. Config supplies a fixed `argv`, allowed `repos` and bounded timeout. Issue
+bodies and model output cannot supply arbitrary verifier shell commands. Prefer
+operator-owned verifier executables outside writable worker workspaces.
+
+Installed capability is not authority to use an account. Optional action adapters
+have fixed argv, exact allowed targets, bounded input fields and explicitly named
+environment variables. The worker sees only their public invocation schemas and
+can propose up to eight actions in the ignored `.agent_actions.json`:
+
+```json
+[{"capability":"publish-recording","target":"approved-channel","input":{"asset":"walkthrough.mp4"}}]
+```
+
+The goal also needs explicit delegation:
+
+```yaml
+allowed_actions:
+  - capability: publish-recording
+    target: approved-channel
+    max_calls: 1
+```
+
+Child grants can narrow, never widen, parent authority. Limits apply across the
+whole tree. Adapters receive structured JSON on stdin with a stable `action_id`;
+they must return `{"receipt": {...}}`. Repeated identical proposals reuse a
+confirmed receipt. Crashes/timeouts leave uncertainty and prevent automatic
+repetition. Reconcile the real remote object before confirming a receipt. No
+exactly-once guarantee is claimed for a provider without idempotency support.
+
+There is no preinstalled video recording/upload adapter in this change. Workers
+must inspect available capabilities, preserve intermediate work and ask a specific
+access/approval question when needed. A script alone cannot pass a recording check.
+General CLI workers still run as trusted host processes; these action gates are
+**not an OS sandbox** against a malicious CLI or shell escape. Do not delegate
+unrestricted accounts or untrusted tasks under a stronger security assumption.
+
+## Controls And Recovery
+
+Use authenticated Telegram commands or their local CLI equivalents:
+
+```text
+/goals
+/goal status g-...
+/goal pause g-... Reason
+/goal resume g-... What changed
+/goal answer g-... Specific answer
+/goal cancel g-... Reason
+/goal accept g-... Reviewed outcome and acceptance reason
+/goal risk g-... Newly observed risk
+/goal actions g-...
+/goal receipt g-... ACTION_ID Verified external receipt reference
+```
+
+`accept` satisfies human checks only; it cannot bypass failed machine checks.
+Answers, risks, prior attempts and decisions are sourced and retained under the
+original goal, not turned into a new unrelated task. Editing an active issue's
+title/body pauses it at source reconciliation; `/goal revise g-...` explicitly
+adopts a new revision, retains the old contract and cancels unfinished old children.
+Changing hierarchy requires a new linked goal. A closed issue without an associated
+merged PR stops unverified work; it is never silently reopened or counted as a
+verified success. Merge-triggered closure can still be awaiting deployment or other
+checks. Use explicit cancellation (or GitHub's not-planned closure) to stop that work.
+
+The existing queue/dispatcher cadence runs reconciliation. Pause/cancel/revision
+stops a monitored worker process group; already performed external effects cannot
+be undone. Expired leases wait for reconciliation rather than blindly retrying.
+Timed quota/capacity waits wake without model calls. Failed local acceptance gets
+bounded correction attempts with verifier feedback. Prepared PR delivery retries
+the GitHub handoff without restarting a worker. Missing result files do not cause
+a fallback if independent checks already prove delivery.
+
+Lifecycle changes and pending GitHub/Telegram notices are one SQLite transaction.
+Delivery retries separately with backoff. GitHub uses one stable status comment.
+Telegram is at-least-once: a lost acknowledgment can yield a duplicate message,
+but does not reset the task outcome. Dashboard alerts expose undelivered notices.
+
+Waiting with a human condition gets `blocked` and `human-required`; verification
+gets `verification-required`. The board uses In Review when available, otherwise
+Blocked. Task-level In Progress requires a worker lease. Parent active status
+means managing children, not a fictitious worker. New Ready issues are intake;
+use goal controls for existing managed waits/revisions, not legacy Retry buttons.
+
+## Dashboard
+
+```bash
+pip install -r requirements.txt
+python -m orchestrator.dashboard.server --port 8765
+```
+
+Open `http://127.0.0.1:8765` on the host. The server is read-only and private by
+default. For remote use, use an authenticated tunnel or the existing shared-secret
+/ Tailscale auth configuration; do not expose an anonymous public listener.
+Tailscale identity headers are accepted only from configured trusted proxies.
+Set allowed hostnames when using a proxy. The systemd user-service template is in
+`contrib/systemd/agent-os-dashboard.service`; monitoring can remain up while
+execution is disabled. No GitHub Actions service is needed for this dashboard.
+
+The Proof view refreshes every 10 seconds and provides hierarchy filters, goal
+details, worker performance, risks, failures, deadlines, retries, actual cost
+coverage and both attempt and intent-to-delivery duration. It distinguishes a
+healthy HTTP connection from a coordinator heartbeat or worker lease. Completion
+without current evidence raises an alert. Outages explicitly mark the retained
+snapshot stale. `/api/observations` exports `proof.observations.v1` without raw
+prompts, file contents, worker output or local workspace paths.
+
+```bash
+python -m orchestrator.delivery --snapshot
+python -m orchestrator.delivery --tick
+python -m orchestrator.delivery status g-...
+```
+
+Proof is pinned to an immutable reviewed commit. Its benchmark/simulated runs are
+a separate product surface and cannot be ingested as live operational evidence.
+Verification strength still depends on the chosen checks. Keyword presence is
+not research quality, a merged PR is not a deployed service, and delivery is not
+measured business impact.
+
+## Migration And Limits
+
+New dispatched work uses the controller. Existing unowned mailbox histories are
+not mass-imported or replayed: their effects and costs may be unknown. Legacy
+model-quality counts remain visible separately, not in the verified denominator.
+To reconcile a selected historical issue without rerunning a worker:
+
+```bash
+python -m orchestrator.delivery adopt owner/repo#355 implementation
+```
+
+Closed issues are independently checked, then verified or retained as cancelled
+without proof; they are not reopened. Open adopted issues start in Backlog and
+require a deliberate resume. Do not adopt an issue while a legacy worker is active.
+The SQLite database is local-host coordination, not distributed fleet consensus.
+
+The default `planning_policy: scoped_delivery` disables speculative growth backlog
+generation and has planner/groomer entrypoints reconcile accepted commitments.
+`legacy_growth` is an explicit opt-in to the former policy. Dispatcher-only mode
+still does not automatically review/merge PRs; preparation is not reported as
+delivery while awaiting that review.
+
+This is a bounded delivery foundation, not proof of an unrestricted autonomous
+company. Remaining boundaries include OS-enforced tool isolation, a real media
+capture/publication pilot, provider billing receipts, domain-specific quality and
+business-impact evaluations, and distributed-host ownership. These are reported
+as unproven, not inferred from the presence of modules or dashboard cards.

docs/deployment-guide.md

@@ -10,6 +10,12 @@ has earned it.
 
 ## Recommended Rollout
 
+The default planning policy is now `scoped_delivery`: execute and reconcile
+accepted commitments instead of inventing growth backlog. See
+[persistent delivery and operations](delivery.md) for project/program contracts,
+the private KPI dashboard, migration and security boundaries. Dispatcher-only
+still leaves PR review/merge to the operator; preparation is not verified delivery.
+
 For a new external repo, the safest path is:
 
 1. Run the demo and confirm the toolchain works.