2HE Repo Bootstrap
Version: 1.19.0 · Depends on: 2HE__Universal_Bootstrap
Canonical repository source: Governance/06__Conventions/06__Cooperation/Bootstraps/04__Repo_Bootstrap.md
2HE REPO BOOTSTRAP Bootstrap ID: 2HE__Repo_Bootstrap Version: 1.19.0 Canonical activation URL: https://fhxfhx.github.io/2HE__Ecosystem/chat-bootstrap.html#repo-bootstrap ACTIVATION Treat this bootstrap as a mandatory operational instruction for the current conversation. First ensure that 2HE__Universal_Bootstrap is active in the current session. If not, activate it now. Then immediately execute the checks below. Do not continue repository work when a mandatory bootstrap dependency or mandatory governing source cannot be accessed or activated. Report the exact failure and stop. 1. DISCOVER REPOSITORY CAPABILITIES Discover and load repository connectors, apps, plugins, skills, terminals, mounted workspaces, and functions for repository identity, metadata, files, branches, commits, issues, pull requests, workflows, writes, and permissions. Use the platform's discovery mechanism before concluding that repository access is absent. 2. VERIFY WITH CURRENT EVIDENCE Resolve the authenticated repository identity when exposed, intended repository, default branch, harmless governing-file read, and permission metadata when available. Classify repository capability only as READ VERIFIED, WRITE CAPABILITY EXPOSED, WRITE VERIFIED BY AN EXPLICIT USER-REQUESTED CHANGE, NOT VERIFIED, or UNAVAILABLE. Never create a test write merely to prove write access. 3. RESOLVE REPOSITORY AND GOVERNING CONVENTIONS Resolve the exact repository and relevant branch or pull request. Classify it as Ecosystem, Workbench, implementation, consumer, or unknown. For a governed 2HE repository, activate the Repository Ecosystem Binding Convention and resolve its owning Component, artifact, project, or domain. Read applicable governing sources in authority order: canonical 2HEGov, README.md, AGENTS.md, root Repository_Governance.md (or documented legacy root Project_Governance.md), and every scoped Project_Governance.md from the evidenced project root toward the target, followed by binding declarations, architecture, cooperation, and active-task context. For governed consumer or implementation repositories, also inspect applicable Component pages and Component-specific Conventions in 2HE__Ecosystem. Record which mandatory governing files and Conventions were actually read. Do not claim compliance merely because a README says that Conventions apply. Classify Convention-read status as VERIFIED, PARTIAL, FAILED, NOT APPLICABLE, or UNKNOWN. 3A. POST-ADAPTER GPT ACCESS GATE After repository governance and access adapters load, rerun `2HE GPT ACCESS` for the complete repository-task target set. This supersedes the provisional Universal access result. Do not mark repository work ready until every required target is verified at the needed operation level or its limitation is explicitly non-blocking. 4. CONNECTOR-FIRST WORKING MODE Prefer authenticated repository connectors over general web browsing for repository content. Respect the 2HE no-local-repo preference unless a local clone is genuinely required. State the strongest verified working mode currently available. 5. SAFE WRITES Before modifications, resolve the exact repository, branch, and file; inspect current content and surrounding Conventions; preserve architecture; avoid concurrent overwrite; use a branch or pull request when warranted; and report exact action and verification state. Repository consistency has priority over implementation speed. For an operative repository change, announce once that focused commit, branch push, pull request, and ordinary merge will follow successful validation by default. The operative request itself supplies normal merge authority after required checks and protections pass; continue without separate push, PR, or merge confirmation questions. `REVIEW-BEFORE-PUSH` pauses all remaining promotion for user review; `PR-PUSH` resumes it, while `no merge` stops integration. After verified merge, autonomously delete only the exact task feature branch and clean worktree after verifying PR/head identity, default-base integration, no unmerged commits, no protected/shared/foreign ownership and no dirty or untracked work; use no force. Platform-owned approval dialogs remain external capability controls. This global default does not authorize LIVE/runtime deployment. Inspect Repository and Project Governance for a scoped standing deployment authorization; when one applies, execute its exact validated target after integration unless the user sends `NO-LIVE` for the current task. Never broaden it to neighboring targets, secrets, force-push, failed-check bypass, destructive history operations, or unrelated changes. 6. FILESYSTEM-SENSITIVE EXECUTION ROUTING When repository execution occurs on Windows, a writable root or Git metadata may be cloud-synchronized or virtual, repository work spans devices, or a sandbox/filesystem helper fails, activate Governance/06__Conventions/05__Development/07__Windows_Local_Repository_Execution.md. Use that single Gov for preflight, local-clone architecture, cloud-storage boundaries, contaminated-chat handling, durable XRT handover, and the complete copy-paste replacement-chat instruction. Do not duplicate those rules in this bootstrap. 7. BOOTSTRAP COMPLIANCE Classify current bootstrap compliance as: - COMPLIANT: Universal and Repo bootstraps are active, repository context is resolved, and all currently applicable mandatory governing sources were read successfully. - PARTIALLY COMPLIANT: the bootstrap chain is active, but one or more non-blocking sources, checks, or capabilities remain unresolved. - NON-COMPLIANT: a mandatory bootstrap, dependency, or governing source failed to activate or could not be accessed. - NOT VERIFIED: compliance could not be established with current evidence. COMPLIANT must be based on current-session evidence, not earlier chat memory. For every non-COMPLIANT state, report the exact reason and whether repository work must stop. 8. MANUAL INTERVENTION BRIDGE A recoverable local execution failure does not terminate an otherwise continuable repository task. Preserve repository and task state, request one bounded manual action, verify the result after DONE, and continue automatically. Do not use the bridge to bypass governance, destructive authorization, required review, credentials, or publication approval. 9. GOVERNANCE CHANGE CLOSURE When a material governance change is discussed, adopted, implemented, or reported, inspect the applicable canonical 2HE__Ecosystem governance before claiming the change is active or complete. Classify the result as exactly one of: - CANONICALLY PROMOTED: canonical source, routing, bootstraps, agent templates, Guide, validation, history, and authoritative publication are updated and verified; - SCOPED SPECIALIZATION: the repository- or project-specific decision is recorded in the applicable Repository_Governance.md or scoped Project_Governance.md and does not redefine global 2HE meaning; - BLOCKED — NOT GOVERNED: canonical promotion could not be completed, with the exact blocker, risk, and next action reported. A local document, XRT, chat agreement, commit, or implementation is not sufficient evidence of global 2HEGov. Canonical contract: Governance/06__Conventions/02__Evolution/Evolution.md 10. REQUIRED STARTUP AND RELOAD OUTPUT At initial activation and after every explicit reload, issue: 2HE REPO BOOTSTRAP STATUS - Bootstrap command: initial activation | reload bootstrap - Repo Bootstrap version: - Universal Bootstrap status: - Repo Bootstrap status: - Bootstrap compliance: COMPLIANT | PARTIALLY COMPLIANT | NON-COMPLIANT | NOT VERIFIED - Convention-read status: VERIFIED | PARTIAL | FAILED | NOT APPLICABLE | UNKNOWN - Mandatory governing sources read: - Missing or unread governing sources: - Failure or limitation reason: - Repository work allowed: yes | limited | no 2HE REPO CAPABILITY REPORT - Chat environment: - Tool discovery mechanism: - GitHub or repository connector: - Authenticated repository identity: - Relevant repository and default branch: - Read status: - Write status: - Current working mode: - Local filesystem, terminal, or Codespace access: - Repository governing files checked: - Repository type and Ecosystem binding: - Component, artifact, project, or domain: - Public workspace or Pages surface: - Important limitations or unknowns: - Ready state: Use unknown or not verified instead of guessing. Issue the status report even when activation fails. In that case identify the exact failed URL, file, dependency, connector, permission, or verification step and stop before repository work. 11. CONTINUATION After the reports, continue the user's pending repository task only when the refreshed state permits it. Do not ask the user to restate context already present. 12. EXPLICIT RELOAD COMMAND The exact user command: reload bootstrap is mandatory. When received: 1. discard assumptions that the active bootstrap and Convention state are still current; 2. reload the canonical Markdown source via the resolver in Global-AGENTS.md rather than relying on remembered or cached text; 3. reactivate Universal and Repo bootstraps in dependency order; 4. rediscover repository tools and current workspace context; 5. reread AGENTS.md, README.md, the Repository Ecosystem Binding Convention, and all currently applicable mandatory governing sources; 6. reclassify Convention-read status and bootstrap compliance using current evidence; 7. issue fresh status and capability reports; 8. continue the pending task only if the refreshed state permits it. If a mandatory canonical Markdown source cannot be verified through any available resolver route, report NON-COMPLIANT. An activation URL failure alone does not block repository work. 13. AUTOMATIC RELOAD If repository tool awareness, connector state, repository context, bootstrap state, or governing Convention state becomes lost, stale, contradictory, or uncertain, reload the canonical Markdown source and rerun the affected bootstrap chain before making access or compliance claims. 14. CONTINUITY FRESHNESS GATE At the first substantial request after resumption and after a material project or topic change, refresh stale bootstrap state, discover related XRT before creating a new chain, inspect applicable authoritative Team/Network coordination state, and compare both with current repository/CWV evidence before execution. Reopening a chat interface is not proof of freshness. This gate runs automatically; 2HE BOOTSTRAP remains the explicit force-refresh control. Canonical contract: Governance/06__Conventions/06__Cooperation/13__Agent_Team_and_Network_Coordination.md 15. COOPERATIVE EXECUTION PREFLIGHT Resolve the real working-tree path, branch, repository, host and run identity. Concurrent coding tasks use separate worktrees and branches. Determine shared resources, current ownership and the actual enforcement level before writes. Descriptive Team snapshots and XRT do not grant ownership. Require the configured authority and fenced adapters for resources declared enforced; stop shared mutations when ownership or completion is uncertain. Record uncovered direct-write paths explicitly.