Operator Governance · Reader View

AI Repo Operating Contract

Repository-wide contract for AI operator behavior.

View canonical Markdown copy Browse registered workspace
Reader View — generated from canonical Markdown.
This page uses the LifeHub Reader Site Styler skill for presentation, but it is still derivative. If it conflicts with the Markdown source, the Markdown controls.
Polished Reader ViewDesigned for study, browsing, and mobile reading.
Markdown Source ViewIn-site display copy for side-by-side verification.
Canonical RuleRepository Markdown remains the source of truth.
Canonical PathLifeHub/08_admin/03_operator/AI_REPO_OPERATING_CONTRACT.md
Source SHA-25612d99b3a33d07d56caef0e8799ed9c2a7e4b5eea7867d302ae8ce950c743b3a2
Generatedregistry-2026-07-06-styler-test
PolicyLifeHub/08_admin/03_operator/READER_VIEW_POLICY.md
Design SkillLifeHub/03_systems/AI_Operator_Continuity/skills/lifehub-reader-site-styler.md

AI Repo Operating Contract (Repository-Wide)

Last updated: 2026-05-30

Purpose

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

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.

Canonical clone model

  • Canonical operational clone (default): /home/cloudhermes/work/LifeHub2.0-cloudrepo-main
  • Preview/sandbox clone: /home/cloudhermes/work/LifeHub2.0-preview-mongumeal
  • Default behavior: start in canonical clone unless task is explicitly preview/sandbox.

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.

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

Startup checklist (every session)

  1. Confirm workdir and git branch.
  2. Confirm target domain and environment (production vs preview).
  3. Load LifeHub/08_admin/03_operator/context_runtime/TIER_A_CORE.md.
  4. Route with LifeHub/08_admin/03_operator/context_runtime/CONTEXT_DIRECTORY.index.json.
  5. Load only the minimum route-selected Tier-C or governance files.
  6. Escalate to Tier-B, navigation, active state, system state, logs, lessons, or skills only when triggered.

Common task -> destination routing

Task type Primary surface
New capture/intake LifeHub/01_inbox
Active project execution LifeHub/02_projects
Reusable method/standard LifeHub/03_systems
SOP/template/checklist LifeHub/04_assets
Requirement/spec contract LifeHub/05_specs
Shared app implementation LifeHub/06_apps
Final report/export/log LifeHub/07_outputs
Governance/routing/structure LifeHub/08_admin

Change-control rule

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

Continuity-guard filename resilience rule

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

Guard behavior standard:

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

Validation standard:

  • Re-run guard scripts after rename changes and require clean exit before calling migration complete.
  • Scan for stale hard-coded references and leave only intentional compatibility fallbacks.

Automation rule

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

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).

Definition of done

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