Commit Governance

160 uncommitted files. Auto-commits that Zach never approved. Agents writing freely but nobody asking "should this be saved?" A commit changes the permanent record -- it is a governance act, not a…

#Why This Method Exists

160 uncommitted files. Auto-commits that Zach never approved. Agents writing freely but nobody asking "should this be saved?" A commit changes the permanent record -- it is a governance act, not a mechanical operation. Writing to disk is work; committing to git is publication. This method specifies who can approve commits and how the system maintains awareness of uncommitted work.

The change review method (methods/47) gates what gets changed. This method gates what gets recorded. They interlock: a change approved at Tier 3 should not require Tier 1 approval to commit, but a commit bundling Tier 1 files must not slip through at Tier 3 authority.

#The Commit Cron

A background job (every 30 minutes) that provides awareness without taking action.

  1. Count uncommitted files via git status --short.
  2. Group them by domain tier using the directory-to-domain mapping from policies/08-domain-authority.md.
  3. Write a summary to data/commit-status.json:
{
  "timestamp": "2026-03-17T07:00:00Z",
  "total_files": 160,
  "by_tier": {
    "tier1": {"count": 3, "domains": ["policies", "ontology"], "files": ["..."]},
    "tier2": {"count": 22, "domains": ["architecture", "methods"], "files": ["..."]},
    "tier3": {"count": 85, "domains": ["projects", "personas", "skills"], "files": ["..."]},
    "tier4": {"count": 50, "domains": ["scripts", "daemons", "data"], "files": ["..."]}
  }
}
  1. The session start hook reads this file and shows agents a one-line summary: 160 uncommitted files: 3 Tier-1 (needs Zach), 22 Tier-2 (needs role authority), 85 Tier-3, 50 Tier-4.

The cron never commits. It observes and reports.

#Commit Approval by Tier

Commits are proposed by any agent but approved according to the highest tier of files included:

Highest tier in commitWho approvesWho is notified
Tier 1 (constitutional)Zach onlyArchitect + Ontologist
Tier 2 (structural)Architect or StrategistZach (informed, not gating)
Tier 3 (domain)Role holder for that domain--
Tier 4 (operational)Steward--

Mixed-tier commits can be split: Tier 3-4 files committed separately by their authorities, Tier 1-2 files batched for Zach's approval. Or the entire commit waits for the highest authority. The proposing agent decides which approach, but must not bundle Tier 1 files into a commit approved only at Tier 3.

#The Historian's Role

The historian mediates the commit process without owning approval authority.

  1. Awareness. The historian reads data/commit-status.json and knows what is uncommitted across the system.
  2. Proposal. When asked (by any agent or the user), the historian groups uncommitted files into logical commit batches -- by session, by domain, by tier. Each batch gets a proposed commit message following conventional commit format.
  3. Routing. The historian identifies which authority approves each batch and sends the proposal to them via dispatch or in conversation with the user.
  4. Execution. Once approved, the historian (or any agent present) runs /commit with the approved scope and message.

The historian does not approve commits. The historian proposes and routes. Approval authority flows from the domain registry (policies/08).

#How Agents Interact With This

  • Any agent can ask: "What's uncommitted?" The commit cron's summary answers.
  • Any agent can propose a commit of their own domain's work: "I changed 3 files in scripts/. Proposed message: feat: add mortality clock script." If all files fall within their tier authority, they can approve themselves.
  • No agent may commit Tier 1 files without Zach's explicit approval. The domain authority hook provides a warning at edit time; this method provides the commit-time gate.
  • The user can always say "commit everything" -- that overrides all tier scoping. Zach's authority is universal.

#Relationship to /commit, /checkpoint, /bye

  • /commit -- the execution mechanism. Still valid, but should only be invoked after approval per this method.
  • /checkpoint -- proposes a mid-session commit. Should present the tier breakdown and route approval before executing.
  • /bye -- proposes a session-end commit. Same: present, route, wait for approval.

None of these should auto-commit. All should propose and wait.


haak method -- 48 -- commit governance -- 2026-03-17 -- designed by Lina (architect, session architect-new). Commits are governance acts, not mechanical operations. The cron observes, the historian proposes, the domain authority approves, the user governs the permanent record.

Methods 48 — Commit Governance — 2026 — Zachary F. Mainen / HAAK