# ChatGPT Adapter

<!-- lifehub-reader-view-link -->
> **Reader View:** [Open the generated HTML reader view](LifeHub/07_outputs/reader_site/pages/chatgpt.html). Markdown remains the canonical source of truth.

## Purpose

This file is the root adapter for ChatGPT-based LifeHub interfaces.

It keeps ChatGPT Project settings lightweight by pointing the conversation interface to the live GitHub source of truth instead of duplicating project rules in static ChatGPT instructions or uploaded source files.

## Live Instruction Entry

For LifeHub-related work in ChatGPT, start from the lean runtime authority below:

1. `LifeHub/08_admin/03_operator/context_runtime/TIER_A_CORE.md`
2. `LifeHub/08_admin/03_operator/context_runtime/CONTEXT_DIRECTORY.index.json`
3. `LifeHub/08_admin/03_operator/UNIVERSAL_CHATGPT_INTERFACE_INSTRUCTIONS.md` only when ChatGPT-interface behavior is in scope
4. `LifeHub/08_admin/03_operator/CHATGPT_INTERFACE_CONTRACT.md` only when interface contract behavior is in scope
5. Project-specific subcontract only when a live repo file exists and adds non-redundant rules for the current ChatGPT Project or Custom GPT.

For the private **LifeHub Command Interface** Custom GPT, the live project-specific subcontract is:

`LifeHub/08_admin/03_operator/custom_gpt_interfaces/LIFEHUB_COMMAND_INTERFACE_CUSTOM_INSTRUCTIONS.md`

## Source Of Truth Rule

The GitHub repository `TheMustardTreeMarket/LifeHub2.0` is the cloud-accessible source of truth for LifeHub.

ChatGPT memory, static Project instructions, uploaded source files, and prior chat history are helpful context only. They must yield to live repository authority when the task depends on current LifeHub state, routing, governance, structure, or project files.

## Owner Reporting Rule

All substantive LifeHub progress and closeout reports must follow:

`LifeHub/08_admin/03_operator/LIFEHUB_OWNER_REPORTING_PROTOCOL.md`

Give Yesh the outcome, status, practical significance, explicit owner action including `None`, and one next operator action. Keep detailed commands, logs, validation matrices, and technical evidence in durable repository or external evidence records and link them. Put a concise TL;DR at the top when the complete response exceeds 750 words.

## Repo Work Execution Surface Rule

For repository work, GitHub-native authorized tools are the default execution surface.

Use GitHub actions/connectors/API tools by default for:

- reading live repository files;
- creating or updating repository documents;
- preparing packets, closeouts, and small direct edits;
- opening, reviewing, updating, or merging PRs when GitHub tooling is sufficient;
- reporting confirmed repository state.

Do not default to the VM merely because the VM is available.

Use a machine/local execution environment only when the task actually requires it, such as:

- Codex Dispatch;
- Hermes Dispatch;
- local tests, builds, generators, linters, formatters, or runtime checks;
- Redis/Docker/local service inspection;
- generated artifacts that require local tooling;
- local-only worktree diagnosis or recovery;
- cases where GitHub-native tooling is unavailable, insufficient, or unsafe for the specific operation.


### Provider-aware bounded execution

For ChatGPT-facing execution, load and apply the canonical `Provider-Aware Bounded Execution Policy` in `LifeHub/08_admin/03_operator/AI_REPO_OPERATING_CONTRACT.md`; when local-agent or independent-worker execution is in scope, also load `LifeHub/08_admin/03_operator/workspace_protection/LOCAL_AI_AGENT_DISPATCH_PROTOCOL.md` before any delegation decision. This root adapter routes to those authorities; it does not restate or override the canonical execution order, failure behavior, output discipline, or safeguard-evasion prohibition.


For local-agent work, load:

`LifeHub/08_admin/03_operator/workspace_protection/LOCAL_AI_AGENT_DISPATCH_PROTOCOL.md`

When the coordinator explicitly invokes `$independent-codex-review-orchestration` or `review_mode: independent_exact_head`, load:

`LifeHub/03_systems/AI_Operator_Continuity/skills/independent-codex-review-orchestration.md`

This is an explicit Independent Review skill, not default context or a general prose classifier. Use the live M1 assurance policy: deterministic work first; A1 requires a reviewer at or above C1; A2 requires C2; A3 requires C3 and fails closed if no autonomous C3 model+adapter pairing meets the critical floor. Resolve model, reasoning, capability, and adapter from the authenticated current-control-plane registry/selector rather than product-name routing. Policy-admitted Independent Review carries standing execution authority for its primary, required challenge, retry, recovery, replacement, and selector-directed fallback; do not ask Yesh to authorize or manually launch reviews. For A1/A2, use the nearest acceptable qualified fallback when the ideal route is unavailable. Primary reviewers must complete the factual exhaustive-coverage contract after any blocker. Apply the policy-defined approval challenge only after qualifying approvals; do not double-review ordinary `CHANGES REQUIRED` results. Do not let the implementation execution approve itself. A correction creates a new head and requires fresh review authority when the candidate remains review-mandated. Review approval creates no merge, credential, activation, deployment, or live-runtime authority.

When concurrent repository-changing candidates may share a dependency, conflict domain, authoritative/shared surface, or runtime/build/deployment boundary, also load:

`LifeHub/03_systems/Agent_Bus/AGENT_BUS_PARALLEL_INTEGRATION_INTERIM_POLICY.md`

That interim policy permits domain-isolated candidates to execute and integrate independently. It requires serialized integration and post-merge revalidation only inside an affected integration group or changed shared surface. It creates no new queue, workflow, task authority, or automatic merge permission and is preserved for later incorporation into Agent Bus.

The dispatch order is **DIRECT EXECUTION FIRST**. Direct deterministic tools and direct ChatGPT-controlled shell/API/repository execution are execution capability; independent model/agent execution is delegation. Delegation is a distinct potentially paid or allowance-consuming action and requires its own authority.

MCP Interim access, Hermes-V1 access, general autonomy, permission to continue a workstream, prior worker use, task difficulty, an available Kanban/dashboard API, or a review requirement do **not** by themselves authorize an arbitrary independent worker. A worker launch is admitted only when the exact worker/job class is explicitly authorized for the current task/workstream or is covered by a scope-matched standing delegation in controlling policy, direct execution is factually insufficient where that condition applies, and resource semantics remain inside the authorized envelope. The narrow standing exception is `policy-admitted independent-review execution`: after review admission it covers the review primary, required challenge, retry, recovery, replacement, and policy-safe fallback without another owner prompt. It does not authorize implementation workers or unrelated Hermes/Adam/Kanban/Codex delegation. A narrower current owner instruction may suspend otherwise standing review execution authority.

Worker dispatch includes indirect launch through a direct wrapper. `owner_exec`, shell, HTTP/API, dashboard, Kanban, or repository tooling must not be used to create an independent worker as a bypass around the worker-authorization gate. Read-only inspection of existing worker state may remain available when separately safe.

Do not assume a direct action will be blocked. If direct execution is actually insufficient, evaluate a worker lane only after the separate worker-dispatch gate is satisfied. The GitHub Dispatch Bridge remains separately gated architecture described in:

`LifeHub/03_systems/LifeHub_Mesh/01_architecture/V1_GITHUB_DISPATCH_BRIDGE_INTERIM_ARCHITECTURE.md`

The bridge does not replace LifeHub Inbox, Taskmaster, project state, or Agent Bus and does not convert work authorization into worker authorization.

When an already-authorized privileged local action is blocked by a real privilege ceiling such as `NoNewPrivs=1`, load `LifeHub/03_systems/AI_Operator_Continuity/skills/dispatch-hermes-privileged-executor.md` only to evaluate the lane. Do not dispatch Hermes/Adam merely because the underlying mutation is authorized; the independent worker itself must also be explicitly authorized under the current controlling source.

When a machine or dispatch bridge is used for repo-related work, state the reason plainly and return repository truth to GitHub through commits, PRs, closeouts, and verified branch state.

## Bootstrap Behavior

When a ChatGPT Project or Custom GPT uses this adapter:

1. Use static Project/GPT instructions only as a bootstrap pointer to this file or to the relevant live Custom GPT subcontract.
2. Fetch `TIER_A_CORE.md` first when GitHub connector access is available and current LifeHub authority matters.
3. Route through `CONTEXT_DIRECTORY.index.json` before loading broader authority.
4. If GitHub cannot be fetched, state the limitation clearly before relying on memory, static files, or prior chat context.
5. Do not claim repository files, inbox items, tasks, settings, dispatches, workers, or runtime states changed unless the relevant tool action succeeded.

## Relationship To AGENTS.md

`AGENTS.md` remains the general repository router for AI operators.

This file is narrower: it defines the ChatGPT interface entrypoint and points ChatGPT to the live instruction contract that governs how ChatGPT Projects and Custom GPTs should use GitHub as authority and select the least indirect safe execution surface.