# 2HE Global Agent Governance Status: Active Version: 2.15.0 Last Updated: 2026-09-24 Changelog: `Global-AGENTS__CHANGELOG.md` This is the single canonical global agent-governance source for every repository bound to 2HE. Repository root `AGENTS.md` files are pointers only. Repository- specific agent rules belong exclusively in root `Internal-AGENTS.md`. Canonical processing architecture: `Governance/06__Conventions/03__Processing/01__Processing.md` ## Canonical Markdown Resolution Repository identity: `fhxfhx/2HE__Ecosystem`. Entry file: `Governance/06__Conventions/06__Cooperation/Global-AGENTS.md`. 1. Discover an existing checkout from workspace configuration or evidenced sibling repositories; verify its remote identity. A directory name alone does not establish authority. Do not create a clone solely for bootstrap. 2. Verify current remote `main` with authenticated repository access or a successful fetch. Read the committed Markdown at that resolved commit, including referenced Bootstrap and governance files. Record repository, source path, commit and retrieval method. A stale local `origin/main`, a version heading, or a modified working-tree file is not freshness proof. 3. If no verified checkout is available, use authenticated repository connector/CLI/API access for the same repository, file and ref. Resolve relative Markdown references against their owning file in that repository. 4. An explicitly authorized version pin is valid for its declared scope; identify it as pinned, not current. If freshness cannot be established and no pin is authorized, report that specific limitation before modification. 5. Pages is an optional generated fallback, not a mandatory first hop. Public bootstrap Markdown is available at `https://fhxfhx.github.io/2HE__Ecosystem/bootstrap/Global-AGENTS.md`. Compare it with canonical Markdown when repository access exists. A Pages mismatch is repaired by publishing canonical sources, never by overwriting canonical Markdown with a newer-looking generated page. 6. Distinguish web-tool cache/safety failures, sandbox network restrictions, HTTP responses, authentication and missing files. Anonymous GitHub access may return 404 for private repositories; use authenticated access before claiming absence. Search-engine indexing is not required for file retrieval. The same resolver applies to initial activation, reloads, and every referenced `Canonical-Source`. `Activation-URL` is a presentation link, not an execution prerequisite. Exhaust available safe source routes before declaring bootstrap non-compliance. Do not distribute unsynchronized governance copies to consumers. ## Gov Manual - Purpose: load authoritative agent rules without depending on one web tool. - Apply when: starting, refreshing, or repairing a governed session. - Core rule: Markdown at verified canonical main (or an authorized pin) governs. - Required actions: resolve the source above, then execute the Processing Chain. - Completion evidence: exact repository/file/ref, read chain and capability state. - Related Govs: Repository Ecosystem Binding, Processing, Repo Bootstrap. ## Mandatory Processing Chain At the first material 2HE request in every new AI/agent session, before changing files or proposing implementation work, execute this chain: 1. Read this complete canonical `Global-AGENTS.md`. 2. Activate `2HE__Universal_Bootstrap`. 3. When repository work is involved, activate `2HE__Repo_Bootstrap`. 4. Read root `Internal-AGENTS.md` completely. If it is missing in an actively governed repository, report bootstrap non-compliance and stop governed modification until repaired. 5. Read repository `README.md`. 6. Read root `Repository_Governance.md` when present. If only a legacy root `Project_Governance.md` exists, read it as the temporary repository layer and report the migration state. 7. Resolve the concrete project from repository evidence whenever a project or project subtree is in scope; then activate `2HE__Project_Bootstrap`. 8. For an active project, read every applicable `Project_Governance.md` from broadest to most specific and read `Project-AGENTS.md` when present. 9. Read additional architecture, status, handover, decision, specification, test, deployment, or publication sources routed from those entry points. 10. Resolve repository type, owning Component/artifact/project/domain, current branch/commit state, implementation state, open work, and intended next direction from evidence; never invent missing binding metadata. 11. Load the smallest applicable canonical governing set from `fhxfhx/2HE__Ecosystem`. 12. Refresh `2HE GPT ACCESS` after repository/project governance has activated any provider/domain access adapters; final `WORK READY` requires this post-adapter probe. 13. Continue and improve the existing system. Do not recreate, fragment, bypass, or silently redefine it. 14. Give only the concise required bootstrap/readiness reports and then continue the user's current task without asking them to repeat discoverable context. For a resumed substantial session or a material project/topic change, run the Continuity Freshness Gate before execution. Refresh stale or uncertain bootstrap state, discover related XRT continuity before creating a new chain, inspect the authoritative team coordination state when applicable, and compare both with the current repository/CWV. A reopened user interface is not evidence that external governance or team state was reloaded. The user need not repeat `2HE BOOTSTRAP`: the participant performs this gate automatically, while `2HE BOOTSTRAP [target]` remains the explicit force-refresh control. Canonical contract: `Governance/06__Conventions/06__Cooperation/13__Agent_Team_and_Network_Coordination.md`. The authority chain is: `2HEGov → Repository_Governance.md → Project_Governance.md → Task CWV` The process chain is: `Universal → Repo → Project when applicable → Task → Execute → Validate → Promote/Publish → Verify → Continue/Evolve`. ## Repository and Project Agent Architecture Every actively governed repository has exactly two root agent files: - `AGENTS.md` — canonical global pointer only; no copied global rules and no repository-specific rules. - `Internal-AGENTS.md` — repository-specific agent instructions and operating information only. A project may additionally have `Project-AGENTS.md` at its evidenced project root. It is project-scoped operating guidance, not a competing governance source. Project governance remains in `Project_Governance.md`. When the repository root is also the root of one project, `Repository_Governance.md` and `Project_Governance.md` may both exist at root: the first governs the repository/container; the second governs the project. ## Agent, Team, and Network Coordination An Agent is an AI-capable Participant operating through a distinct task, chat, process, or automation context. A Team is an operational unit coordinating shared outcomes. A Network connects otherwise distinct Participants or Teams across scopes without merging their authority, ownership, or execution state. Keep four layers distinct: operational coordination (for example a project-owned RAgents surface), semantic continuity (XRT), raw conversation evidence, and the canonical repository/project CWV. Operational state may link XRT records but does not replace them, and neither state becomes canonical merely by existing. Before concurrent mutation, apply the cooperative execution safety contract in `13__Agent_Team_and_Network_Coordination.md`: resolve participant/task/run and resource identity, isolate worktrees, acquire actual ownership, and verify fencing at the adapter. Report protection per resource as isolated, coordinated_manual, enforced, or unavailable. XRT and Pages never grant leases. Shared mutations without verified ownership wait; independent isolated work may continue. Never imply fixture validation enrolled an existing chat or runtime. ## Governance-Level Terminology Use only `Global Governance`, `Repository Governance`, `Project Governance`, and `Task CWV` for authority levels. `Local Governance` is not a governance level. `Local` may describe a filesystem, checkout, runtime, cache, or other physical execution context. Rules stored in a repository or project are called repository-specific or project-specific according to their actual scope. ## Dynamic Project Scope Project instructions are activated by the current discussion/task scope, not by chat history alone. Whenever the material target changes project: - prove the project root from repository evidence; - refresh Project Bootstrap; - load its governance chain and `Project-AGENTS.md` when present; - apply those instructions only to that project scope. Do not allow project-specific decisions to disappear merely because a different chat or agent continues the work, and do not leak one project's rules into an unrelated project. ## Capability and Execution Status Before repository work, discover and use available repository capabilities. Do not claim a capability is unavailable before tool/plugin/connector discovery or an actual access attempt when the platform provides discovery. Maintain a current execution status covering at least read, create, update, delete, branch/PR/merge when relevant, execution environment, publication/ deployment capability, and authorization state. A capability is verified only by current-session evidence or explicit current tool metadata. Do not create destructive or externally visible test actions merely to verify capability. When ordinary repository reads, file edits, and tests succeed but a Git write fails because the managed sandbox exposes `.git` as read-only, classify that as an intentional authorization boundary rather than a damaged sandbox or a `2he win chk` trigger. Request the platform's narrowly scoped approval for the required branch, stage, commit, or merge operation and continue after approval. Start sandbox or ACL recovery only when evidence identifies an actual setup, ACL, process-launch, shell, or filesystem failure. When a requested implementation cannot occur because required capability is missing, state exactly: `NO IMPLEMENTATION OCCURRED` and name the missing capability. Never allow planning language to imply that an implementation was performed. ## Source Integrity and Decision Codes Never imply that a requested document was read when only a search result, cache, mirror, HTML page, earlier edition, summary, or other substitute source was available. For PDFs, distinguish `PDF VERIFIED`, `PDF TEXT ONLY`, `DERIVED WEB COPY`, and `PDF INACCESSIBLE`; render and inspect relevant pages when visual structure can affect meaning. Exhaust available safe local parsing fallbacks before requesting installation or user intervention. Every multiple-choice question shall give each alternative a short, stable, topic-scoped semantic response code, such as `PDF-UPLOAD` or `DEPLOY-WAIT`. The user may reply with the code alone. Bare ordinals may aid scanning but shall not be the sole durable identifier when decisions can coexist or branch. Canonical contract: `Governance/06__Conventions/06__Cooperation/12__Source_Integrity_and_Decision_Codes.md`. ## Manual Intervention Bridge A recoverable local capability failure shall not terminate an otherwise continuable task. When a safe bounded user action can bridge the missing capability, activate the Manual Intervention Bridge defined by the Processing Convention. Provide one exact manual checkpoint, preserve completed work and pending state, wait for `DONE` or the actual output, verify the result, and continue automatically without repeating completed work. `DONE` confirms only the named checkpoint and grants no additional authority. For command-line checkpoints, use clipboard-first textual handoff whenever available: capture complete combined stdout and stderr as one plain-text block, copy it to the system clipboard even on failure, and ask the user to paste that text into the chat. Use screenshots only for genuinely visual or GUI evidence, or when clipboard transfer is unavailable. Prefer one robust pasteable block or single command line and avoid detached control-flow fragments. ## Portable Bootstrap Control The canonical conversational control is: `2HE BOOTSTRAP [target]` When operatively sent, execute or reload the complete applicable Processing Chain and report current capability/CRUD, repository, project, governance, and ready state before continuing the pending task. A completely new vendor chat cannot be expected to know a private 2HE command before loading governance. The provider-neutral cold-start instruction is: `Read Governance/06__Conventions/06__Cooperation/Global-AGENTS.md from fhxfhx/2HE__Ecosystem at verified main using an existing checkout or authenticated repository access, then execute 2HE BOOTSTRAP.` Use Canonical Markdown Resolution above; no browser or Pages visit is required. The command is provider-independent after the canonical source is loaded. ## Canonical Sources and Binding Primary repository: `https://github.com/fhxfhx/2HE__Ecosystem` Always applicable for governed repository/project work as relevant: - `Governance/06__Conventions/03__Processing/01__Processing.md` - `Governance/06__Conventions/05__Development/03__Repository_Ecosystem_Binding.md` - `Governance/06__Conventions/05__Development/04__Project_Specific_Conventions.md` - `Governance/06__Conventions/06__Cooperation/Bootstraps/03__Universal_Bootstrap.md` - `Governance/06__Conventions/06__Cooperation/Bootstraps/04__Repo_Bootstrap.md` - `Governance/06__Conventions/06__Cooperation/Bootstraps/05__Project_Bootstrap.md` - `Governance/06__Conventions/Conventions.md` Conditionally applicable for Windows repository execution, cloud-synchronized or virtual writable roots, cross-device repository work, and filesystem-helper failures: - `Governance/06__Conventions/05__Development/07__Windows_Local_Repository_Execution.md` Conditionally applicable when an exact source, PDF, user decision, or multiple-choice question is involved: - `Governance/06__Conventions/06__Cooperation/12__Source_Integrity_and_Decision_Codes.md` Conditionally applicable whenever access readiness, access repair, or workflow recovery is involved: - `Governance/06__Conventions/06__Cooperation/14__GPT_Access_and_Recovery.md` Failure to retrieve a public orientation page is not by itself a reason to stop. Apply Canonical Markdown Resolution to every required source before declaring it unavailable. ## Binding Rules No governed repository is canonically autonomous. It is bound to all applicable General 2HE Conventions; global Conventions, Standards, and Specifications; Component/artifact/project/domain-specific governance; and valid scoped requirements that do not contradict higher canonical meaning. Canonical shared meaning remains in `fhxfhx/2HE__Ecosystem`. Repository and project code, configuration, implementation state, decisions, specialization, and documentation remain in their owning scope. Scoped content supplements canonical governance; it does not replace it. When canonical Markdown and a generated Guide/Pages surface differ, canonical Markdown and the applicable repository/project CWV govern. ## 2HE DO When a user instruction begins with operative `2HE DO ` followed by a target, complete that target through the full governed end-to-end cycle: bootstrap, scope resolution, implementation, validation, applicable workspace/Guide updates, focused commit, safe synchronization and push, promotion to `main` when permitted, deployment/publication when applicable, and external verification. Recover autonomously from ordinary failures until success or a real blocker is established. Do not wait for separate commit/push/deploy requests. `2HE DO` does not authorize unrelated changes, force-pushes, history destruction, secret publication, required-review bypass, unrelated external communication, or destructive work outside the named target. Canonical contract: `Governance/06__Conventions/05__Development/02__End_to_End_Execution.md`. ## Default PR, Push, and Integration Completion An operative request to change a governed repository proceeds by default through focused commit, branch push, pull request, and integration after successful validation when checks, review, and authority permit. Announce this default once in a short progress message; do not ask a blocking confirmation question or repeat the complete lifecycle. The operative change request itself supplies ordinary merge authority for the focused result after required checks and repository protections pass. Do not request a second confirmation for push, PR creation, or normal merge. This standing default never permits bypassing required review, branch protection, failed checks, or scope boundaries. The user may reply `REVIEW-BEFORE-PUSH` before push to pause the remaining promotion path, including merge, then resume with `PR-PUSH`. Explicit `repository only`, `do not push`, `no PR`, or `no merge` instructions also pause the corresponding promotion stage. Read-only advice, diagnosis, status, and review do not activate this default. The default never authorizes LIVE/runtime deployment, secrets, unrelated changes, destructive history operations, force-push, failed-check bypass, or unrelated external communication. After a focused pull request is verified as merged into authoritative `main`, the same completion authority includes deleting its exact remote feature branch and removing its clean local branch/worktree. First verify the merged PR and default base, confirm that no head commit remains unmerged, and exclude default, protected, release, environment, shared integration, dirty-worktree, untracked- work, or another active participant's branches. Use ordinary non-force deletion only. If any gate fails, retain the branch and report why; do not ask the user to perform routine safe cleanup. ### Scoped standing deployment authorization The global default still does not authorize LIVE/runtime deployment. A user may, however, establish a durable standing authorization for one named repository, project, artifact, or runtime target. Such an authorization is active in future sessions only after it is recorded in the applicable Repository or Project Governance and loaded by bootstrap. The record shall name the exact scope, trigger, validated deployment interface, required post-deployment verification, and a stable per-task opt-out code. It may not authorize unrelated targets, unsafe deletion, protection bypass, secrets, force-push, or failed validation. When an applicable standing authorization exists, a successful integrated change to its named target proceeds through the recorded deployment and verification stages without another confirmation. `NO-LIVE` is the canonical per-task opt-out unless the scoped record defines a more specific stable code. The participant shall report when a restart or other user-side activation step remains necessary; deployment alone shall not be described as runtime-loaded. ## Mandatory Completion Closures Every material completion or handoff shall report token usage as a separate line. Use the exact measured value and scope exposed by the current runtime (for example task, goal, turn, or session). Never present an estimate as a measurement. When the runtime exposes no trustworthy counter for the relevant scope, report `Token usage: unavailable in this runtime` instead of inventing a number. If an earlier reported budget or estimate differs from measured usage, label both values and their scopes explicitly. Token reporting is cost and capacity evidence; it does not replace outcome, validation, deployment, or remaining-work evidence. After repository work involving unpublished commits, end with exactly one applicable push-readiness state defined by current Repo Bootstrap: `PUSHBEREIT`, `WARTEN`, or `NO PUSH REQUIRED`. The final state means that no repository commit requires publication; it does not mean that the user's task was inapplicable. After a material governance change, inspect applicable canonical governance and end with exactly one: `CANONICALLY PROMOTED`, `SCOPED SPECIALIZATION`, or `BLOCKED — NOT GOVERNED`. A chat agreement, scoped file, XRT, branch, or proposal is not global governance until canonically promoted. ## Registered Conversational Controls The canonical command registry is: `Governance/08__Specifications/02__Command_Reference.md`. - `COMMANDS [filter]` — show registered commands with class and status. - `reload bootstrap` — compatibility alias for `2HE BOOTSTRAP` reload. - `2HE BOOTSTRAP [target]` — load/refresh the full applicable bootstrap chain. - `2HE GPT ACCESS [targets]` — prove task-relevant access with current-session probes and report immediate readiness. - `2HE GPT ACCESS REPAIR [targets]` — repair recoverable access failures, re-probe, restore the workflow checkpoint, and resume. - `ADDISON HELP: ` — retrieve local ADDISON help evidence, answer directly, and cite file, page, and section. - `2HE DO ` — execute the full named end-to-end work cycle. - `REVIEW-BEFORE-PUSH` — pause default repository promotion before push. - `PR-PUSH` — resume the focused branch/PR promotion path; does not authorize LIVE. - `NO-LIVE` — opt out of an applicable scoped standing LIVE deployment for the current task. - `GOV PULL ` — read the coherent canonical governance set. - `GOV UPDATE ` — execute governance-specific end-to-end update. - `xrt`, `xrt aus context `, `xrt-del-codespace` — follow the current Chat Context Export, Dynamic Memory Transcript, and Codespace Preservation Conventions. - `xcq` and `xcq ` — follow the owning repository/cooperation semantics registered in the Command Reference. - `Pages Update` — follow its registered repository-local publication scope. Quoted examples and discussion do not activate commands. For XRT, continuity, handoff, transcript chaining, conversation-memory, agent team, network, or operational coordination work, load: - `Governance/06__Conventions/06__Cooperation/09__Chat_Context_Export.md` - `Governance/06__Conventions/06__Cooperation/10__XRT_Dynamic_Memory_Transcript_System.md` - `Governance/06__Conventions/06__Cooperation/13__Agent_Team_and_Network_Coordination.md` Use the mandatory continuation order defined there and preserve transcript privacy and provenance. Plain `xrt` targets a device-independent durable private handover. Keep a local Git-ignored capture copy, retain the reviewed semantic segment and registry in the approved private Git archive, and retain available privacy-preflighted raw evidence as compressed content-addressed objects in the approved private XRT LFS. Keep raw and semantic resolvers distinct and verify both before reporting `durable_handover`; otherwise report `local_capture`. When authenticated access exists, query the private XRT registry for the evidenced entity, area, project, and topic before concluding that no related handover exists. Use the semantic fast path for ordinary continuation. Resolve and fetch the raw blob only when exact wording, image/tool evidence, provenance, or omitted detail is required. The device-local XRT LFS mount is configured with `TWOHE_XRT_LFS_ROOT`; the canonical Google Drive logical root is `My Drive/PROJECTS/UP2/PROJECTS/2HE/2HE-PRODUCTS/2HE-App/LFS/XRT`. Stable `xrt-lfs://sha256/...` resolvers never contain a machine-specific drive letter. ## Governance Operations `GOV PULL` and `GOV UPDATE` are governed by: `Governance/06__Conventions/05__Development/06__Governance_Operations_and_Manuals.md`. A global governance update is complete only after canonical source, version, changelog, affected routing/bootstrap/agent/Guide surfaces, validation, promotion to `main`, deployment when applicable, and public verification agree. Report the highest verified state when blocked. ## Canonical Language Write canonical Guide pages, Bootstrap instructions, Bootstrap registries, command references, and repository/project agent-bootstrap templates in English. This does not constrain the language used to communicate with the user. ## Guiding Principle Enter the real environment, repository, project, and task deliberately; inherit the complete valid authority chain; execute only with verified capability; and do not call work complete until the requested result actually exists and is verified.