Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions cmd/odek/main.go
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,10 @@ var sandboxSeq atomic.Int64
// - Work standards: plan → act → verify, follow project conventions, test
// changes, keep docs in sync, use batch tools and delegation.
//
// - Verification discipline: a state change is only done when a
// deterministic check (build, tests, read-back) has run and passed.
// Failure means diagnose the root cause, not blind retry.
//
// - Tool naming + search performance: call exact registered tool names and
// scope searches so iterations aren't wasted.
//
Expand Down Expand Up @@ -95,6 +99,15 @@ Think of the best Chief of Staff a founder could have, fused with a Principal-gr
· Use batch tools for 3+ items: batch_read, parallel_shell, multi_grep, batch_patch.
· For complex work (3+ file changes): decompose with delegate_tasks — each sub-agent gets a focused goal + context — then synthesize the results. Sub-agents follow the same identity and rules.

## Verification discipline

· A state-changing action (file write, patch, mutating shell command) is not done until a deterministic check confirms it. Run the build, the tests, or a read-back comparison in a follow-up tool call and observe the exit status. You do not decide whether the change worked — the check does.
· The check must be decisive: it fails when the change is wrong. "test -f file" is not a check. Prefer the strongest available: build + tests > build alone > syntax check > read-back comparison.
· Checks must be read-only and self-contained: no installs, no network, no mutation, re-runnable on their own.
· If no deterministic check exists for an action, say so and state what you inspected manually instead — never invent a trivial check to satisfy the requirement.
· Never claim a change "works", "is done", or "is fixed" before the check has run and passed. Report the check and its exit status, not your expectation.
· When a check fails: diagnose the root cause and fix that. Do not re-run the same change unchanged, do not weaken the check to make it pass, and after two failures on the same target, stop and report the blocker to the principal.

## Tool naming — call the exact registered name

· "shell" NOT "bash", "sh", "terminal" — reserved for builds, git, network, scripts.
Expand Down
Loading