Suggested Use

ClankerOS works best as a local operating loop for agentic work, not as a black-box autonomous runner. Use it to make work visible, verifiable, and harder to overclaim.

I Want To

If you want to...	Start with...
Learn the basics	`docs/getting-started.md`
Pick a practical operator recipe	`docs/operator-recipes.md`
Understand the vocabulary	`docs/concepts.md`
Understand the local architecture	`docs/architecture.md`
Find a command quickly	`docs/reference-commands.md`
See current state	`python3 -m agent_os.cli dashboard`
Inspect registered projects	`docs/tutorial-project-registry.md`
Build a project context packet	`python3 -m agent_os.cli project-context <project>`
Plan a registered project goal without executing it	`docs/tutorial-goal-lifecycle.md`
Execute one planned task with local verifier evidence	`docs/tutorial-run-task.md`
Pick the next safe local task	`python3 -m agent_os.cli iterate`
Resume a workspace safely	`docs/tutorial-operator-daily-loop.md`
Run the first loop	`docs/tutorial-first-loop.md`
Make a coded change safely	`docs/tutorial-approval-gated-coding.md`
Capture subagent-style context without execution	`docs/tutorial-subagent-delegation-results.md`
Run a read-only delegation through a fake local adapter	`docs/tutorial-executable-delegation.md`
Generate deterministic context for a scout delegation	`python3 -m agent_os.cli context-pack <delegation_id>`
Scout registered repo files with a local adapter	`profile-adapter ... --working-directory project_root`
Prepare a bounded coding plan from a handoff	`python3 -m agent_os.cli coder-prep <delegation_id>`
Review a run before acting	`python3 -m agent_os.cli review <run_id>`
Keep activation blocked while preserving proof state	start with the capability follow-up tutorials below
Publish a coherent snapshot	`docs/tutorial-public-snapshot.md`

Registered Project Goal Lifecycle

Use the lifecycle commands when you want a durable planning packet before execution:

python3 -m agent_os.cli register-project my-repo --path /absolute/path/to/repo --test-command "python3 -m pytest -q"
python3 -m agent_os.cli project-context my-repo
python3 -m agent_os.cli goal "Make one small verified improvement" --project my-repo
python3 -m agent_os.cli plan goal_...
python3 -m agent_os.cli contract goal_...
python3 -m agent_os.cli tasks goal_...
python3 -m agent_os.cli dashboard

The goal command creates local SQLite rows and markdown artifacts for a goal, plan version, and planned tasks under .clanker/projects/<project>/goals/<goal_id>/. The contract command creates or reads the local scope and verification agreement for the latest plan. Use update-task to record operator-visible task state and replan to create a new plan version when scope changes:

python3 -m agent_os.cli update-task task_... --status blocked --blocked-reason "Needs operator review."
python3 -m agent_os.cli replan goal_... --reason "Scope changed after contract review."

Proof boundary: this lifecycle does not execute tasks, claim work, run tests, commit, push, deploy, open PRs, call model providers, or start subagents. Planned tasks remain status=planned until run-task, a later runner, or an operator deliberately advances them.

For the full walkthrough, use docs/tutorial-goal-lifecycle.md.

Running One Planned Task

Use run-task after the goal has a sprint contract and you have picked one planned task:

python3 -m agent_os.cli run-task task_... --profile tester
python3 -m agent_os.cli review run_...
python3 -m agent_os.cli task-recommendations --goal goal_...
python3 -m agent_os.cli dashboard

Use tester only when the task verifier is the registered project default test command. Use coder for other safe local verifier commands. The command records a routing decision, local shell verifier output, task/plan-step state, and a .clanker/projects/<project>/goals/<goal_id>/runs/<run_id>/evidence/ packet.

If a verifier fails or a planned task is blocked, task-recommendations records durable local review/replan guidance and writes docs/task-recommendations.md. It does not retry, reset, replan, or dispatch tasks automatically.

Proof boundary: run-task does not edit files by itself, commit, push, deploy, open PRs, call model providers, start subagents, schedule retries, promote trust, or mutate external systems.

For the full walkthrough, use docs/tutorial-run-task.md.

Scout A Registered Repo Before Editing

Use this loop when you want a local scout to map relevant files before a coding agent or operator edits anything:

python3 -m agent_os.cli register-project clankeros --path "$PWD" --test-command "python3 -m pytest -q"
python3 -m agent_os.cli goal "Map executable delegation files before editing" --project clankeros
python3 -m agent_os.cli tasks <goal_id>
python3 -m agent_os.cli delegate <task_id> --profile scout --title "Find relevant files"
python3 -m agent_os.cli context-pack <delegation_id> --max-files 12 --max-snippets 8
python3 -m agent_os.cli profile-adapter scout --command "python3 /absolute/path/to/scout.py" --input-mode json_file --output-mode json --working-directory project_root
python3 -m agent_os.cli run-delegation <delegation_id>
python3 -m agent_os.cli delegation-result <delegation_id>
python3 -m agent_os.cli implementation-handoff <delegation_id>
python3 -m agent_os.cli coder-prep <delegation_id>
python3 -m agent_os.cli coder-worktree-plan <delegation_id>
python3 -m agent_os.cli review <run_id>

The context pack gives the scout a ranked file list, search hits, snippets, test hints, entrypoint hints, and config hints. The adapter can read payload["context_pack"]["json_path"] and return a file_relevance_report or implementation_options result without ClankerOS calling any model provider.

Proof boundary: this scout loop writes local evidence and proposed memory only when requested. It does not edit files, commit, push, deploy, approve effects, schedule retries, or mutate external systems.

Use coder-prep after a readable implementation handoff when you want a bounded future coding packet without starting implementation. It writes coder_prep.json and coder_prep.md, marks the plan operator_review_required, and reports zero task rows, runs, routing decisions, worktrees, approvals, source edits, command reruns, network actions, and external mutations. Use coder-worktree-plan after reviewing coder_prep.md when you want a bounded future worktree/run plan without creating the worktree. It writes coder_worktree_plan.json and .md, marks the gate operator_approval_required, keeps dispatch_ready=false, and reports zero task rows, runs, routing decisions, worktrees, approvals, source edits, command reruns, network actions, provider calls, and external mutations. Use coder-commit-request only after a completed coder worktree run has appeared in a review packet and its diff is acceptable. The request still does not stage or commit. approve-coder-commit records the explicit operator decision without staging or committing. commit-coder-worktree is the separate local step: it re-checks reviewed evidence, branch/HEAD, changed files, outside files, commit message, and verifier output before creating one commit in the isolated worktree branch. Use the printed effect_id with github-handoff only when you want local push and draft-PR instructions. None of these commands push, deploy, call providers, or mutate external systems.

Good Starting Prompts

Use prompts that name a concrete local outcome:

Create a local proof packet for enabling a hosted dashboard, but do not deploy it.

Review the current expansion evidence and add the next report-only approval boundary.

Review the dashboard and next-iteration packet, then implement the next local proof step with tests and explicit non-claims.

Explain what is locally proven, what is only a report, and what still needs operator approval.

Run the first local loop, regenerate the dashboard, and summarize what is proven and not proven.

Register this git repo, run a worktree-isolated coding task, capture the diff and tests, then ask me before creating the local worktree commit.

List registered projects, write a project context packet for the target repo, and tell me what ClankerOS knows before running work.

List the safe default profiles and record a scout routing decision for repo search without dispatching a model.

Record a read-only scout delegation contract for this task and show me the delegation artifact, but do not start a subagent.

Configure a fake local scout shell adapter, run this pending delegation, show me the evidence packet, and keep provider/network non-claims precise.

Register this repo, create a scout delegation for the next planned task, run the adapter from the project root, and show me the repo files it marked relevant.

Run the scout delegation, then show me the implementation-handoff readback, context-pack validation, and the review/dashboard handoff sections.

Run coder-prep for this implementation handoff and show me the allowed files, run plan, and zero-effect counters before editing anything.

Attach this read-only delegation output to the existing contract, validate the schema, and keep the no-provider/non-network claims explicit.

Propose a project memory entry from that completed delegation result, but leave it inactive until I approve it.

Propose a reusable project skill from that verified run, but leave it inactive until I approve it.

Write a human-first review, evidence index, and replay summary for this run before deciding the next action.

Write a steering review for this goal, show the next action, and list the inbox without executing or approving anything.

Apply the operator approval request schema after I approve the generated selection template, and prove that no approval rows were created.

Create pending operator approval request rows from the latest expansion approval draft after I approve the row-creation selection, and prove no legacy approval requests were created.

Decide pending operator approval request rows after I approve the decision selection, and prove that no capabilities or legacy approval requests were activated.

Review ingested capability follow-up results, accept keeping activation blocked, and prove that no approval rows or activation actions were created.

Create proposed effects from accepted blocked follow-up result decisions, and prove that capability activation remains blocked.

Review downstream proof-plan result records, accept keeping activation blocked, and prove that no approval rows, activation actions, or external mutations were created.

Create proposed effects from accepted downstream proof-plan result decisions, and prove that activation remains blocked.

Apply proposed downstream proof-plan result decision effects as local records only, and prove that activation remains blocked.

Create downstream proof tasks from applied downstream result decision effects, and prove that activation remains blocked.

Route downstream result effect tasks to read-only evaluator delegation packets, and prove that no subagent starts.

Review downstream result-effect task result records, accept keeping activation blocked, and prove that no approval rows, activation actions, or external mutations were created.

Apply proposed downstream result effect task result decision effects as local records only, and prove that capability activation remains blocked.

Create downstream proof tasks from applied downstream result effect task result decision effects, and prove that capability activation remains blocked.

Route downstream result effect task result effect tasks to read-only evaluator delegation packets, and prove that no subagent starts.

Ingest completed downstream result effect task result effect delegation outputs, and prove that activation remains blocked.

Review downstream result effect task result effect result records, accept keeping activation blocked, and prove that no approval rows, activation actions, or external mutations were created.

Create proposed effects from accepted downstream result effect task result effect result decisions, and prove that capability activation remains blocked.

Apply proposed downstream result effect task result effect task result effect task result decision effects as local records only, and prove that capability activation remains blocked.

Ingest completed downstream result effect task result effect task result effect delegation outputs, and prove that activation remains blocked.

Review downstream result effect task result effect task result effect task result records, accept keeping activation blocked, and prove that no approval rows, activation actions, or external mutations were created.

Create proposed effects from accepted downstream result effect task result effect task result effect task result decisions, and prove that capability activation remains blocked.

Create downstream proof tasks from applied downstream result effect task result effect task result effect task result decision effects, and prove that capability activation remains blocked.

Route downstream result effect task result effect task result effect task result effect tasks to read-only evaluator delegation packets, and prove that no subagent starts.

Ingest completed downstream result effect task result effect task result effect task result effect delegation outputs, and prove that activation remains blocked.

Review downstream result effect task result effect task result effect task result effect task result records, accept keeping activation blocked, and prove that no approval rows, activation actions, or external mutations were created.

Review downstream result effect task result effect task result effect task result effect task result effect task result records, accept keeping activation blocked, and prove that no approval rows, activation actions, or external mutations were created.

Create proposed local effects from accepted downstream result effect task result effect task result effect task result effect task result decisions, and prove that no approval rows, activation actions, or external mutations were created.

Create proposed local effects from accepted downstream result effect task result effect task result effect task result effect task result effect task result decisions, and prove that no approval rows, activation actions, or external mutations were created.

Apply proposed downstream result effect task result effect task result effect task result effect task result decision effects as local records only, and prove that capability activation remains blocked.

Route downstream result effect task result effect task result effect task result effect tasks to read-only evaluator delegation packets, and prove that no subagent starts.

Ingest completed downstream result effect task result effect task result effect task result effect task result effect delegation outputs, and prove that activation remains blocked.

Apply proposed downstream result effect task result effect task result effect task result effect task result effect task result decision effects as local records only, and prove that capability activation remains blocked.

Create downstream proof tasks from applied downstream result effect task result effect task result effect task result effect task result effect task result decision effects, and prove that capability activation remains blocked.

Route downstream result effect task result effect task result effect task result effect task result effect task result effect tasks to read-only evaluator delegation packets, and prove that no subagent starts.

Ingest completed downstream result effect task result effect task result effect task result effect task result effect task result effect task delegation outputs as local result records, and prove that capability activation remains blocked.

Recommended Operating Loop

Pick one narrow capability or boundary.
Write or update a red-first regression when behavior changes.
Add the smallest implementation that creates durable local evidence.
Regenerate the relevant report and docs/dashboard.md.
Run python3 -m pytest -q.
Run python3 -m agent_os.cli eval.
Record specialist delegation results when read-only context is useful.
Propose memory from completed delegation results only when the fact is small and reusable.
Propose skills from verified run evidence only when the procedure is reusable.
Write review, evidence, and replay-summary packets before operator decisions on meaningful runs.
Run steer, next-action, and inbox when the next operator move is unclear.
Apply local schema changes only through explicit operator approval commands.
Create local operator approval rows only through explicit operator approval commands.
Decide local operator approval rows only through explicit operator approval commands.
Review ingested capability follow-up results before treating them as an activation decision.
Convert accepted blocked follow-up result decisions into proposed effects only after the review decision exists.
Review downstream proof-plan result records before treating the next evidence plan as operator-accepted.
Convert accepted downstream proof-plan result decisions into proposed effects only after the downstream review decision exists.
Apply downstream result decision effects as local records only after the proposal row exists.
Materialize applied downstream result decision effects into pending downstream proof tasks before routing or delegation.
Route downstream result effect tasks into read-only delegation packets before ingesting more proof-plan output.
Review downstream result effect task result records before treating the next evidence plan as operator-accepted.
Convert accepted downstream result effect task result decisions into proposed effects only after the downstream review decision exists.
Apply downstream result effect task result decision effects as local records only after the proposal row exists.
Materialize applied downstream result effect task result decision effects into pending downstream proof tasks before routing or delegation.
Route downstream result effect task result effect tasks into read-only delegation packets before ingesting the next proof-plan output.
Ingest completed downstream result effect task result effect delegation outputs as local result records before any operator review.
Review downstream result effect task result effect task result effect task result effect task result effect task result records before treating the next evidence plan as operator-accepted.
Convert accepted downstream result effect task result effect task result effect task result effect task result effect task result decisions into proposed effects only after the downstream review decision exists.
Apply downstream result effect task result effect task result effect task result effect task result effect task result decision effects as local records only after the proposal row exists.
Review downstream result effect task result effect result records before treating the next evidence plan as operator-accepted.
Convert accepted downstream result effect task result effect result decisions into proposed effects only after the review decision exists.
Route downstream result effect task result effect task result effect tasks into read-only delegation packets before ingesting the next proof-plan output.
Ingest completed downstream result effect task result effect task result effect delegation outputs as local result records before any operator review.
Review downstream result effect task result effect task result effect task result records before treating the next evidence plan as operator-accepted.
Convert accepted downstream result effect task result effect task result effect task result decisions into proposed effects only after the review decision exists.
Apply downstream result effect task result effect task result effect task result decision effects as local records only after the proposal row exists.
Materialize applied downstream result effect task result effect task result effect task result decision effects into pending downstream proof tasks before routing or delegation.
Route downstream result effect task result effect task result effect task result effect tasks into read-only delegation packets before ingesting the next proof-plan output.
Ingest completed downstream result effect task result effect task result effect task result effect task result effect delegation outputs as local result records before any operator review.
Review downstream result effect task result effect task result effect task result effect task result effect task result records before treating the next evidence plan as operator-accepted.
Materialize applied downstream result effect task result effect task result effect task result effect task result effect task result decision effects into pending downstream proof tasks before routing or delegation.
Record non-claims before treating the work as safe.

Approval-Gated Coding Loop

Use this loop when the desired outcome is an actual local code change:

python3 -m agent_os.cli register-project <name> --path /path/to/repo --test-command "python3 -m pytest -q"

Inspect the registry entry and write a durable project context packet:

python3 -m agent_os.cli projects
python3 -m agent_os.cli project-status <name>
python3 -m agent_os.cli project-context <name>

Run the change in an isolated worktree:

python3 -m agent_os.cli run-goal "Make the smallest verified change" --project <name> --isolation worktree --command "<safe local command>"

Inspect docs/dashboard.md, especially ## Operator Cockpit.
Read runs/<run_id>/evidence/diff.patch, tests.txt, verification.json, effect.json, and approval.md.
Use python3 -m agent_os.cli approve <approval_id> --decided-by operator --note "..." only after the diff, tests, and policy evidence are acceptable.
Use python3 -m agent_os.cli commit-approved <approval_id> --committed-by operator to re-check evidence and create the local worktree commit exactly once.
Use python3 -m agent_os.cli github-handoff <effect_id> --base main --title "..." when you want a local push/draft-PR packet after commit evidence exists.
Use python3 -m agent_os.cli ci-deploy-evidence <github_handoff_id> --provider github-actions --status success --external-run-id <run_id> --url <run_url> after real CI/deploy evidence exists and should be preserved locally.
Use python3 -m agent_os.cli profiles, profile-show <name>, and route ... to record profile routing choices before specialist work.
Use python3 -m agent_os.cli delegate <task_id> --profile scout --title "..." to create a read-only delegation contract when specialist prep is useful.
Use python3 -m agent_os.cli record-delegation-result <delegation_id> --summary "..." --output-json '{...}' to attach structured read-only output to an existing delegation.
Use python3 -m agent_os.cli memory propose-from-delegation <delegation_id> --key "..." to create an inactive memory proposal from completed delegation evidence.
Use python3 -m agent_os.cli memory approve <memory_id> --approved-by operator only after reviewing the proposal.
Use python3 -m agent_os.cli skill propose --project <name> --name "..." --description "..." --from-run <run_id> to create an inactive reusable SKILL.md proposal from run evidence.
Use python3 -m agent_os.cli skill approve <skill_id> --approved-by operator only after reviewing the generated SKILL.md.
Use python3 -m agent_os.cli review <run_id>, evidence <run_id>, and replay-summary <run_id> to create operator-readable run packets before making follow-up decisions. evidence also writes a replayable packet under .clanker/projects/<project>/goals/<goal_id>/runs/<run_id>/evidence/.
Use python3 -m agent_os.cli cleanup-worktrees --confirm --reason "..." after reviewing terminal effects and deciding the worktree can be removed.

commit-approved blocks without committing if the worktree base commit, patch, changed files, or stored test command no longer match the approved evidence. github-handoff requires committed local effect evidence, writes a local handoff packet, and prints operator git push plus gh pr create --draft commands while recording network_actions_taken=0. ci-deploy-evidence requires a GitHub handoff packet and records operator-supplied proof while also recording network_actions_taken=0. profiles creates safe local planner/coder/scout/tester/evaluator defaults and .clanker/profiles.yml. route records profile selection decisions for task ids or category/project pairs without claiming tasks or calling model providers. delegate stores a scoped pending delegation contract and JSON artifact under .clanker/delegations/; it does not start a subagent, call a model provider, write files, approve work, commit, or mutate external state. record-delegation-result marks a delegation completed only after structured operator-supplied output matches the expected schema family. It writes a local result artifact and preserves network_actions_taken=0. memory propose-from-delegation creates a proposed memory entry from a completed delegation result. It writes local JSON evidence and does not make the memory active until memory approve is run. skill propose creates a proposed skill record and writes .clanker/skills/<name>/SKILL.md from run evidence. It records a skill version and does not make the skill active until skill approve is run. review, evidence, and replay-summary write local Markdown packets under runs/<run_id>/ and expose them in the dashboard. evidence also writes goal-scoped JSON/JSONL/Markdown packet files for goal, plan, contract, tasks, routing decisions, delegations, steering reviews, commands, approvals, effects, memory/skill proposals, incidents, eval candidates, verification summary, git_status.txt, diff.patch, and changed_files.json. When command-proof files already exist from run-task, the aggregate evidence export uses sidecars such as verification-summary.json and operator-summary.md instead of overwriting the executable proof. These commands do not rerun commands, approve effects, commit, push, deploy, or mutate external systems. steer <goal_id> writes a local steering review from existing goals, tasks, approvals, and incidents. next-action <goal_or_project> refreshes that review and prints the recommended operator move. inbox lists operator-worthy steering reviews, pending approvals, and open incidents. They do not execute tasks, approve work, retry, commit, push, deploy, or mutate external systems. cleanup-worktrees removes only clean terminal worktrees; dirty blocked worktrees are recorded as blocked and left in place.

Reading The Reports

Prefer these files when orienting:

docs/next-iteration.md for the next suggested local work packet.
docs/getting-started.md for the short first-use path.
docs/concepts.md for the project vocabulary.
docs/architecture.md for the local-first control-plane shape.
docs/reference-commands.md for a compact command map.
docs/dashboard.md for the current operational view.
docs/OPERATING_SUMMARY.md for architecture and guardrails.
docs/tutorial-subagent-delegation-results.md for the profile routing, delegation contract, and result-ingestion loop.
docs/tutorial-run-review.md for human-first run review, evidence indexing, and conceptual replay.
docs/tutorial-steering-inbox.md for deterministic steering reviews, next-action output, and local inbox triage.
docs/tutorial-capability-followup-result-decisions.md for reviewing ingested follow-up evidence while keeping activation blocked.
docs/tutorial-capability-followup-result-effect-proposals.md for creating proposed local effects from accepted blocked follow-up decisions.
docs/tutorial-capability-followup-result-task-results.md for ingesting completed downstream proof-plan delegation outputs as local result records.
docs/tutorial-capability-followup-result-task-decisions.md for reviewing downstream proof-plan result records while keeping activation blocked.
docs/tutorial-capability-followup-result-task-result-effect-proposals.md for creating proposed local effects from accepted downstream result decisions.
docs/tutorial-capability-followup-result-task-result-effect-task-results.md for ingesting completed downstream result effect task delegation outputs.
docs/tutorial-capability-followup-result-task-result-effect-task-decisions.md for reviewing downstream result effect task result records while keeping activation blocked.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-proposals.md for creating proposed effects from accepted downstream result effect task result decisions.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-application.md for applying proposed downstream result effect task result decision effects as local records.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-tasks.md for creating pending downstream proof tasks from applied downstream result effect task result decision effects.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-delegations.md for routing downstream result effect task result effect tasks to read-only evaluator delegation packets.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-results.md for ingesting completed downstream result effect task result effect delegation outputs as local result records.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-decisions.md for reviewing downstream result effect task result effect result records while keeping activation blocked.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-results.md for ingesting completed downstream result effect task result effect task result effect delegation outputs as local result records.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-decisions.md for reviewing downstream result effect task result effect task result effect task result records while keeping activation blocked.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-proposals.md for creating proposed effects from accepted downstream result effect task result effect result decisions.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-application.md for applying proposed downstream result effect task result effect result decision effects as local records.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-tasks.md for creating pending downstream proof tasks from applied downstream result effect task result effect task result effect task result decision effects.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-application.md for applying proposed downstream result effect task result effect task result effect task result effect task result decision effects as local records.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-tasks.md for creating pending downstream proof tasks from applied downstream result effect task result effect task result effect task result effect task result decision effects.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-results.md for ingesting completed downstream result effect task result effect task result effect task result effect task result effect task result effect task delegation outputs.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-decisions.md for reviewing downstream result effect task result effect task result effect task result effect task result effect task result effect task result records while keeping activation blocked.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-proposals.md for creating proposed effect rows from accepted downstream result effect task result effect task result effect task result effect task result effect task result effect task result decisions.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-results.md for ingesting completed downstream result effect task result effect task result effect task result effect task result effect delegation outputs.
docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-decisions.md for reviewing downstream result effect task result effect task result effect task result effect task result effect task result records while keeping activation blocked.
contracts.md for safety boundaries and evidence expectations.
status.md for chronological implementation evidence.
projects/bootstrap/handoff.md for the current continuation edge.

Approval Boundaries

Allowed actions are not actions taken. A report may list choices such as approve, defer, and request_more_evidence while still preserving:

selected_action=none;
actions_taken=0;
selections_recorded=0;
zero migration/table/approval-row creation counters.

Treat those zeros as intentional safety evidence. Do not cross them without an explicit operator-approved flow and fresh verification.

When the generated schema migration selection template is ready, the narrow approved crossing is:

python3 -m agent_os.cli expansion-operator-approval-schema-migration-apply \
  --operator-id operator \
  --selected-action approve \
  --selection-note "Approved local operator approval request schema." \
  --evidence-reference docs/expansion-operator-approval-schema-migration-selection-input-template.md

That command may create the local operator_approval_requests table. It must still report operator_approval_rows_created: 0 and approval_requests_created: 0.

After the table exists, the narrow approved row-creation crossing is:

python3 -m agent_os.cli expansion-operator-approval-request-rows-apply \
  --operator-id operator \
  --selected-action approve \
  --selection-note "Approved local operator approval request row creation after reviewing the draft packet." \
  --evidence-reference docs/expansion-operator-approval-draft.md

That command may create pending local operator_approval_requests rows from the latest expansion approval draft. It must still report approval_requests_created: 0, and it does not decide, promote, route, deploy, or mutate external systems.

After pending rows exist, the narrow local decision crossing is:

python3 -m agent_os.cli expansion-operator-approval-request-decide \
  --operator-id operator \
  --selected-action approve \
  --selection-note "Approved pending operator approval requests after reviewing evidence." \
  --evidence-reference docs/expansion-operator-approval-request-rows-application.md

That command may update pending local operator_approval_requests rows to approved, deferred, or more_evidence_requested depending on the selected action. It must still report approval_requests_created: 0, and it does not enable capabilities, promote trust, route work, deploy, or mutate external systems.

After approved rows exist, create proposal records without applying them:

python3 -m agent_os.cli expansion-operator-approval-effect-proposals

This command writes proposed effect rows for approved local operator approval requests and links each row back to the original operator request. It must still report legacy_approval_requests_created: 0 and activation_actions_taken: 0; it does not enable capabilities, promote trust, route work, schedule workers, retry work, track spend, deploy, or mutate external systems.

After proposed effects exist, apply them as local records:

python3 -m agent_os.cli expansion-operator-approval-effect-apply \
  --operator-id operator \
  --selection-note "Apply approved local operator approval effect proposals as local records only." \
  --evidence-reference docs/expansion-operator-approval-effect-proposals.md

This command may move operator approval effects from proposed to applied and write local application evidence. It must still report legacy_approval_requests_created: 0, activation_actions_taken: 0, and capability_enabled=false; it does not enable hosted dashboard, remote workers, schedulers, adapters, CI/deploy, budget enforcement, trust promotion, automatic retry, real-cost tracking, or external systems.

After applied capability effects exist, create pending activation-gate tasks:

python3 -m agent_os.cli capability-activation-tasks

This command creates one pending high-risk task per applied capability effect and links each task back to its source effect. It must still report activation_actions_taken: 0; the tasks are guardrails for future evidence and approval work, not capability enablement.

Turn those pending activation tasks into blocked evidence and approval contracts:

python3 -m agent_os.cli capability-activation-contracts
python3 -m agent_os.cli dashboard

This creates one blocked activation contract per pending activation task. Each contract records required artifacts, required commands, explicit_operator_approval_required, and blocked_until_evidence_verified. It must still report approval_requests_created: 0 and activation_actions_taken: 0; it does not create approval_requests rows or enable capabilities.

Attach local evidence and record the current operator decision:

python3 -m agent_os.cli capability-activation-evidence \
  --all \
  --evidence-kind proof_checklist \
  --evidence-reference docs/capability-activation-contracts.md \
  --verification-command "python3 -m agent_os.cli capability-activation-contracts" \
  --verification-status blocked \
  --recorded-by operator \
  --summary "Current activation contracts are present but still missing capability-specific proof."
python3 -m agent_os.cli capability-activation-decide \
  --operator-id operator \
  --selected-action request_more_evidence \
  --selection-note "Requested capability-specific proof before any activation decision." \
  --evidence-reference docs/capability-activation-evidence.md

This records local evidence rows and a local decision state for each contract. It does not approve capability activation. In the current blocked proof state, the safe decision is request_more_evidence.

Turn the request_more_evidence decisions into pending queue work:

python3 -m agent_os.cli capability-activation-followups
python3 -m agent_os.cli dashboard

This creates one pending high-risk capability_activation_followup_task per contract that needs more evidence. It is task graph state for future evidence collection; it does not create approval rows, satisfy proof, or enable capabilities.

Turn the pending follow-up evidence tasks into read-only delegation packets:

python3 -m agent_os.cli capability-activation-followup-delegations
python3 -m agent_os.cli dashboard

This records routing decisions to the evidence_review category and creates pending evaluator delegation packets with local JSON artifacts. It does not start subagents, call model providers, create approval rows, satisfy proof, or enable capabilities.

After an operator records a completed evaluator result with record-delegation-result, ingest those completed follow-up results into the capability evidence trail:

python3 -m agent_os.cli capability-activation-followup-results
python3 -m agent_os.cli dashboard

This writes local result records and JSON artifacts for completed read-only evaluator delegation results. It keeps approval_requests_created=0, activation_actions_taken=0, activation_allowed=false, and capability_enabled=false; the record is evidence for operator review, not proof satisfaction or capability enablement.

Record the local operator review decision over ingested results:

python3 -m agent_os.cli capability-activation-followup-result-decide \
  --operator-id operator \
  --selected-action accept_keep_blocked \
  --selection-note "Accepted evaluator result and kept capability activation blocked." \
  --evidence-reference docs/capability-activation-followup-results.md
python3 -m agent_os.cli dashboard

This writes docs/capability-activation-followup-decisions.md and a local decision row for result records that have not already been reviewed. It keeps approval_requests_created=0 and activation_actions_taken=0; the accept_keep_blocked action is an operator review state, not capability enablement.

After accepted blocked follow-up result decisions exist, create proposed effect rows:

python3 -m agent_os.cli capability-activation-followup-result-effect-proposals
python3 -m agent_os.cli dashboard

This writes docs/capability-activation-followup-result-effect-proposals.md and local proposed effect rows in the generic effects ledger. It keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false; the effect row is a traceable local proposal, not capability enablement.

After proposed follow-up result effects exist, apply the accepted blocked effects locally and materialize the next downstream proof task:

python3 -m agent_os.cli capability-activation-followup-result-effect-apply \
  --operator-id operator \
  --selection-note "Apply accepted blocked follow-up result effect proposals as local records only." \
  --evidence-reference docs/capability-activation-followup-result-effect-proposals.md
python3 -m agent_os.cli capability-activation-followup-result-tasks
python3 -m agent_os.cli capability-activation-followup-result-task-delegations
python3 -m agent_os.cli dashboard

The task command writes docs/capability-activation-followup-result-tasks.md and creates one pending capability_activation_followup_result_task per applied follow-up result effect that has not already been materialized. It preserves source decision, result, delegation, follow-up task, contract, and capability links while keeping approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

The delegation command writes docs/capability-activation-followup-result-task-delegations.md and creates read-only evaluator delegation packets for pending capability_activation_followup_result_task rows that do not already have a packet. It keeps execution_started=0, network_actions_taken=0, external_mutations_taken=0, and activation_actions_taken=0; the packets are local proof-planning contracts, not worker execution.

After a downstream proof-plan delegation has been completed by recording an operator-supplied structured result, ingest it as a local downstream result record:

python3 -m agent_os.cli record-delegation-result <delegation_id> \
  --summary "Evaluator drafted the next evidence plan while keeping activation blocked." \
  --output-json '{"evidence":[{"status":"planned","summary":"Collect hosted dashboard proof."}],"findings":[{"summary":"Keep activation blocked."}]}'
python3 -m agent_os.cli capability-activation-followup-result-task-results
python3 -m agent_os.cli dashboard

The result command writes docs/capability-activation-followup-result-task-results.md, stores one local result row per completed downstream delegation, and writes JSON artifacts under docs/capability-activation-followup-result-task-results/. It keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false; the result is a preserved evidence plan, not capability activation or proof satisfaction.

Review those downstream result records explicitly before using them as accepted operator posture:

python3 -m agent_os.cli capability-activation-followup-result-task-result-decide \
  --operator-id operator \
  --selected-action accept_keep_blocked \
  --selection-note "Accepted downstream proof-plan result and kept capability activation blocked." \
  --evidence-reference docs/capability-activation-followup-result-task-results.md
python3 -m agent_os.cli dashboard

The decision command writes docs/capability-activation-followup-result-task-decisions.md and records the selected operator action for downstream result records that have not already been decided. It keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

Convert accepted blocked downstream result decisions into local proposed effects:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-proposals
python3 -m agent_os.cli dashboard

The proposal command writes docs/capability-activation-followup-result-task-result-effect-proposals.md and creates proposed rows in the generic effects ledger for accepted downstream result decisions. It keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false; it does not apply the proposed effects.

Apply accepted blocked downstream result decision effects as local records:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-apply \
  --operator-id operator \
  --selection-note "Apply accepted downstream proof-plan result effect proposals as local records only." \
  --evidence-reference docs/capability-activation-followup-result-task-result-effect-proposals.md
python3 -m agent_os.cli dashboard

The application command writes docs/capability-activation-followup-result-task-result-effect-application.md, records a local application row, and marks applicable proposed effects as applied. It keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

Create downstream proof tasks from applied downstream result decision effects:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-tasks
python3 -m agent_os.cli dashboard

The task command writes docs/capability-activation-followup-result-task-result-effect-tasks.md, records a local batch row, and creates pending high-risk task graph records for applied downstream result decision effects that do not already have a downstream task. It keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

Route downstream result effect tasks into read-only evaluator delegation packets:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-delegations
python3 -m agent_os.cli dashboard

The delegation command writes docs/capability-activation-followup-result-task-result-effect-task-delegations.md, records local routing and delegation batch rows, and writes pending delegation JSON artifacts under .clanker/delegations/. It keeps execution_started=0, network_actions_taken=0, external_mutations_taken=0, approval_requests_created=0, activation_actions_taken=0, activation_allowed=false, and capability_enabled=false.

After a downstream result effect task delegation has been completed by recording an operator-supplied structured result, ingest it as a local result record:

python3 -m agent_os.cli record-delegation-result <delegation_id> \
  --summary "Evaluator drafted downstream result-effect proof evidence while keeping activation blocked." \
  --output-json '{"evidence":[{"status":"planned","summary":"Collect downstream result-effect proof evidence."}],"findings":[{"summary":"Keep activation blocked."}]}'
python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-results
python3 -m agent_os.cli dashboard

The result command writes docs/capability-activation-followup-result-task-result-effect-task-results.md, stores one local result row per completed downstream result effect task delegation, and writes JSON artifacts under docs/capability-activation-followup-result-task-result-effect-task-results/. It keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false; the result is a preserved evidence plan, not capability activation or proof satisfaction.

Review downstream result effect task result records with an operator decision:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-decide \
  --operator-id operator \
  --selected-action accept_keep_blocked \
  --selection-note "Accepted downstream result-effect proof-plan result and kept capability activation blocked." \
  --evidence-reference docs/capability-activation-followup-result-task-result-effect-task-results.md
python3 -m agent_os.cli dashboard

The decision command writes docs/capability-activation-followup-result-task-result-effect-task-decisions.md, records the operator action in SQLite, and keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

Create proposed effects from accepted downstream result effect task result decisions:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-proposals
python3 -m agent_os.cli dashboard

The proposal command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-proposals.md, creates generic local effects rows with idempotency keys, and keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false. It does not apply the proposed effects; that is the next local application-record slice.

Apply accepted downstream result effect task result decision effects as local records:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-apply \
  --operator-id operator \
  --selection-note "Apply accepted downstream result-effect task result effect proposals as local records only." \
  --evidence-reference docs/capability-activation-followup-result-task-result-effect-task-result-effect-proposals.md
python3 -m agent_os.cli dashboard

The application command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-application.md, records a local application row, and marks applicable proposed effects as applied. It keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

Create downstream proof tasks from those applied effects:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-tasks
python3 -m agent_os.cli dashboard

The task command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-tasks.md, records a local batch row, and creates pending high-risk task graph records for applied downstream result effect task result decision effects that do not already have a downstream task. It keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

Route those downstream result effect task result effect tasks into read-only evaluator delegation packets:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-delegations
python3 -m agent_os.cli dashboard

The delegation command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-delegations.md, records local routing and delegation batch rows, and writes pending delegation JSON artifacts under .clanker/delegations/. It keeps execution_started=0, network_actions_taken=0, external_mutations_taken=0, approval_requests_created=0, activation_actions_taken=0, activation_allowed=false, and capability_enabled=false.

After a downstream result effect task result effect delegation has been completed by recording an operator-supplied structured result, ingest it as a local result record:

python3 -m agent_os.cli record-delegation-result <delegation_id> \
  --summary "Evaluator drafted downstream result-effect task result-effect proof evidence while keeping activation blocked." \
  --output-json '{"evidence":[{"status":"planned","summary":"Collect downstream result-effect task result-effect proof evidence."}],"findings":[{"summary":"Keep activation blocked."}]}'
python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-results
python3 -m agent_os.cli dashboard

The result command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-results.md, stores one local result row per completed downstream result effect task result effect task delegation, and writes JSON artifacts under docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-results/. It keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false; the record is the next preserved evidence plan, not capability activation or proof satisfaction.

Review those downstream result effect task result effect result records before they drive the next local effect proposal:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-decide \
  --operator-id operator \
  --selected-action accept_keep_blocked \
  --selection-note "Accepted downstream result-effect task result-effect proof-plan result and kept capability activation blocked." \
  --evidence-reference docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-results.md
python3 -m agent_os.cli dashboard

The decision command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-decisions.md, records the operator action, and keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

Create proposed local effects from accepted downstream result effect task result effect result decisions:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-proposals
python3 -m agent_os.cli dashboard

The proposal command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-proposals.md, creates generic local effects rows for accepted blocked decisions, and keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

Apply those proposed effects as local application records:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-apply \
  --operator-id operator \
  --selection-note "Apply accepted downstream result-effect task result-effect task result effect proposals as local records only." \
  --evidence-reference docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-proposals.md
python3 -m agent_os.cli dashboard

The application command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-application.md, records a local application row, marks applicable generic effects rows as applied, and keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

Materialize those applied effects into pending downstream proof tasks:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-tasks
python3 -m agent_os.cli dashboard

The task command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-tasks.md, creates pending high-risk local proof tasks, and keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

Route those pending tasks to read-only evaluator delegation packets:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-delegations
python3 -m agent_os.cli dashboard

The delegation command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-delegations.md, records local evidence_review routing decisions and pending evaluator delegation packets, and keeps execution_started=0, network_actions_taken=0, external_mutations_taken=0, activation_actions_taken=0, activation_allowed=false, and capability_enabled=false. The packet is a local proof-planning contract, not subagent execution.

Route the next pending downstream proof tasks to read-only evaluator delegation packets:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-delegations
python3 -m agent_os.cli dashboard

The delegation command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-delegations.md, records local evidence_review routing decisions and pending evaluator delegation packets, and keeps execution_started=0, network_actions_taken=0, external_mutations_taken=0, approval_requests_created=0, activation_actions_taken=0, activation_allowed=false, and capability_enabled=false. The packet is still a local proof-planning contract, not subagent execution.

After an operator records a completed evaluator output, ingest that local result artifact:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-results
python3 -m agent_os.cli dashboard

The result command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-results.md, creates local result records and per-result JSON artifacts, and keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, capability_enabled=false, and proof satisfaction blocked. Missing result artifacts are reported without creating result rows.

After the result record exists, record the operator review decision:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-decide \
  --operator-id operator \
  --selected-action accept_keep_blocked \
  --selection-note "Accepted downstream result-effect task result-effect task result-effect task result-effect proof-plan result and kept capability activation blocked." \
  --evidence-reference docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-results.md
python3 -m agent_os.cli dashboard

The decision command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-decisions.md, records the operator action against local result ids, and still keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

After an accepted blocked decision exists, create the local proposed effect:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-proposals
python3 -m agent_os.cli dashboard

The proposal command writes docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-proposals.md, creates idempotent generic effects rows for accepted blocked decisions, and still keeps approval_requests_created=0, activation_actions_taken=0, external_mutations_taken=0, activation_allowed=false, and capability_enabled=false.

The same pattern now extends to the deeper downstream result-effect task-result ladder. For the latest proposal rung, use:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-proposals

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-proposals.md for the exact expected proposal report, idempotency check, and safety counters.

To apply those accepted blocked proposals as local ledger records only, run:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-apply --operator-id operator --selection-note "Apply accepted downstream result-effect task result-effect task result-effect task result-effect task result-effect task result-effect task result effect proposals as local records only." --evidence-reference docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-proposals.md

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-application.md for the application report and idempotency check.

After those local application records exist, create the next pending proof tasks:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-tasks
python3 -m agent_os.cli dashboard

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-tasks.md for the expected task batch report and idempotency check.

After those pending proof tasks exist, route them into read-only evaluator delegation packets:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-delegations
python3 -m agent_os.cli dashboard

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-delegations.md for the delegation packet report, idempotency check, and safety counters.

After an operator records structured output for one of those delegation packets, ingest the completed result:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-results
python3 -m agent_os.cli dashboard

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-results.md for the result record report, artifact path, idempotency check, and safety counters.

After the latest result record exists, record the operator review decision:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-decide \
  --operator-id operator \
  --selected-action accept_keep_blocked \
  --selection-note "Accepted downstream result-effect task result-effect task result-effect task result-effect task result-effect task result-effect task proof-plan result and kept capability activation blocked." \
  --evidence-reference docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-results.md
python3 -m agent_os.cli dashboard

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-decisions.md for the decision report, idempotency check, and safety counters.

After the latest accepted blocked decision exists, create the local proposed effect row:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-proposals
python3 -m agent_os.cli dashboard

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-proposals.md for the proposal report, idempotency check, and safety counters.

After the latest proposed effect row exists, apply it as a local application record:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-apply \
  --operator-id operator \
  --selection-note "Apply accepted downstream result-effect task result-effect task result-effect task result-effect task result-effect task result-effect task result-effect task result effect proposals as local records only." \
  --evidence-reference docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-proposals.md
python3 -m agent_os.cli dashboard

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-application.md for the application report, idempotency check, and safety counters.

After the latest application row exists, materialize the next downstream proof task:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-tasks
python3 -m agent_os.cli dashboard

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-tasks.md for the task report, idempotency check, and safety counters.

After those latest pending proof tasks exist, route them into read-only evaluator delegation packets:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-delegations
python3 -m agent_os.cli dashboard

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-delegations.md for the delegation batch report, packet JSON location, idempotency check, and safety counters.

After an operator records structured output for one of those latest delegation packets, ingest the completed result:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-results
python3 -m agent_os.cli dashboard

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-results.md for the result record report, artifact path, idempotency check, and safety counters.

After that latest result record exists, record the next local operator review decision:

python3 -m agent_os.cli capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-decide \
  --operator-id operator \
  --selected-action accept_keep_blocked \
  --selection-note "Accepted downstream result-effect task result-effect task result-effect task result-effect task result-effect task result-effect task proof-plan result and kept capability activation blocked." \
  --evidence-reference docs/capability-activation-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-results.md
python3 -m agent_os.cli dashboard

See docs/tutorial-capability-followup-result-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-result-effect-task-decisions.md for the decision report, idempotency check, and safety counters.

When To Commit And Push

Commit when:

the scope is coherent;
generated reports match the current state;
python3 -m pytest -q passes;
git diff --check is clean;
the commit message describes the operational increment.

Push after the branch target and remote are explicit. For the public GitHub repo, prefer main only for verified snapshots that are useful to share. For a fuller checklist, use docs/tutorial-public-snapshot.md.

Practical Next Slices

Good next slices now favor operator review for the latest ingested downstream result records, then the local effect-proposal and application rungs that keep activation blocked:

operator review decisions for downstream result effect task result effect task result effect task result effect task result effect task result effect task result effect task result effect task result records;
local decision-effect proposals from accepted blocked decisions;
local application records for accepted blocked decision-effect proposals;
per-request operator decision targeting and inbox refinement;
hosted-dashboard proof only after local commit and CI/deploy evidence is modeled;
remote-worker, scheduler, browser/desktop adapter, budget, trust, retry, and real-cost surfaces only after their evidence and approval contracts can be enforced.

Each slice should end with explicit non-claims. That discipline is the point: the system should show what is safe to trust, what is only locally proven, and what remains blocked.

FilesExpand file tree

suggested-use.md

Latest commit

History