Skip to content

Objectives

Objectives are versioned contracts in Git: for work large enough to span multiple cards and components, the WHAT (outcome), WHY (context, decisions) and DONE (acceptance criteria, verification contract) are written down as a reviewed Markdown document and merged via PR before and alongside execution.

What this section contains

  • Active objectives (active/) — objectives currently owned and being executed by the Lead. Today: three — the Harness V3.1 pilot (OBJ-HARNESS-V31-001), the docs.wetopi.net internet publication pilot (OBJ-EDGE-DOCS-001 / PROJ-EDGE-DOCS-001), and the secrets vault harness (OBJ-VAULT-001 / PROJ-VAULT-001) plus the docs-runtime rebuild (OBJ-DOCSRUNTIME-001 / PROJ-DOCSRUNTIME-001).
  • Completed objectives (completed/) — objectives whose verification contract passed and whose verdict is recorded. A completed objective is moved here unchanged (its history lives in Git; the file is never edited after completion except for the status front-matter field).
  • Templates (templates/) — the objective specification (REF-OBJECTIVE-SPEC-TEMPLATE) and the Execution Ledger (PROC-EXECUTION-LEDGER-TEMPLATE).

What this is NOT

  • Not a second Kanban. Card state, assignment, dispatch and run history stay in the Kanban board (and the Work Ledger that will supersede it) — DocOps §1 level-1 operational state. An Objective never records card state; it references card IDs only where the verification contract needs them as evidence anchors.
  • Not an execution ledger in Git. The Execution Ledger (single writer: the Lead) is a level-1 operational document maintained outside this repo's contract layer; only its shape is standardized here, via the template.
  • No live state, no secrets. Objectives never contain live snapshots, .env files, auth.json, tokens, connection URLs, credential hashes or pool output (see the no-secret policy in the objective template).

Mechanism (summary)

The Architect (THINK) drafts WHAT/WHY/DONE; the Lead (OWN) lands the reviewed Objective in Git, decomposes it into cards and maintains the ledger; workers (DO) implement; an independent reviewer (JUDGE) verifies the delivery against the contract. Every gate is conditional and fail-closed. Full model: ADR-0008 (proposed) and ARCH-HARNESS-V31-GOVERNANCE.

Start here

  1. OBJ-HARNESS-V31-001 — the Harness V3.1 pilot (the governance mechanism itself, proven on the pilot).
  2. OBJ-EDGE-DOCS-001 / PROJ-EDGE-DOCS-001 — publish docs.wetopi.net on internet with working HTTPS via edge WAN v1 (runbook Phase 8 pilot).
  3. OBJ-VAULT-001 / PROJ-VAULT-001 — secrets vault harness (ADR-0009).
  4. OBJ-DOCSRUNTIME-001 / PROJ-DOCSRUNTIME-001 — docs runtime rebuild via GitHub webhook.
  5. OBJ-WPDOCTOR-001 — WPDoctor, agente ADK SRE para estates WordPress/WooCommerce por SSH (M0+M1, ADR-0017).
  6. REF-OBJECTIVE-SPEC-TEMPLATE — how to write one.
  7. ADR-0008 — why this mechanism exists.