Operator Governance

AI Repo Operating Contract

Repository-wide contract for AI operator behavior.

Open Markdown View Browse Workspace

Generated from canonical Markdown. Markdown controls.

Section 01

Purpose

Repository-wide operating contract for any AI operator/agent working in LifeHub. This is not app-specific.

Section 02

Source-of-truth rule

Repository files are authoritative.
Chat is execution interface, not canonical memory.
Important decisions must be written to the correct file surface.

Section 03

Action Surface Precedence

For Custom GPT / connector-enabled operation, the GitHub connector/action is the default surface for ordinary repository reads and writes. Use local repository worktrees only when local execution is required.

Section 04

Canonical clone model

Canonical operational clone for local VM operations: /home/cloudhermes/work/LifeHub2.0-cloudrepo-main
Preview/sandbox clone: /home/cloudhermes/work/LifeHub2.0-preview-mongumeal
Default local behavior: use the canonical clone for read-only inspection, clean synchronization, or task-worktree creation unless task is explicitly preview/sandbox. Do not use the canonical clone itself as a routine editing surface.

Section 05

Common task -> destination routing

Section 06

Change-control rule

Any change affecting behavior, structure, ownership, runtime, monitoring, or deployment must update relevant authoritative docs in the same change set.

Section 07

Cross-clone boundary rule

Never edit the same logical artifact in both clones during one task unless doing an intentional sync.
If intentional sync is required, state it explicitly in task notes and validate both trees after edit.

Section 08

Scope coverage all domains

Any AI operator must support and route work across: - LifeHub/01_inbox intake and triage - LifeHub/02_projects active project execution - LifeHub/03_systems reusable methods and continuity systems - LifeHub/04_assets SOPs/templates/checklists - LifeHub/05_specs requirements and behavior contracts - LifeHub/06_apps shared/cross-project implementation - LifeHub/07_outputs final reports and operator logs - LifeHub/08_admin governance and navigation authority

LifeHub/01_inbox intake and triage
LifeHub/02_projects active project execution
LifeHub/03_systems reusable methods and continuity systems
LifeHub/04_assets SOPs/templates/checklists

Section 09

Startup checklist every session

1. Confirm workdir and git branch.

Confirm target domain and environment (production vs preview).
Load LifeHub/08_admin/03_operator/context_runtime/TIER_A_CORE.md.
Route with LifeHub/08_admin/03_operator/context_runtime/CONTEXT_DIRECTORY.index.json.

Section 10

Continuity-guard filename resilience rule

When governance files are renamed for neutrality or clarity, update continuity/onboarding guards in the same change set.

Prefer the current canonical filename first.
Keep prior-name compatibility fallback only as a non-authoritative backup.
Add pattern fallback for future variants when appropriate (for example _REPO_OPERATING_CONTRACT.md).
Never keep a legacy filename as a hard requirement after a canonical rename.

Section 11

Automation rule

All LifeHub-related cron jobs must pin workdir to the intended clone path.

Section 12

Periodic consistency check

Run lightweight drift checks weekly and after major infra/runtime changes. Reference: HERMES_WEEKLY_DOC_CONSISTENCY_CHECK.md (filename retained; rule applies to all AI operators).

Section 13

Definition of done

Task artifacts are written to correct repository surfaces.
Routing/governance docs remain consistent.
No important decision is left only in chat.