# Concentrated OAP — Reusable Bootstrap-Package Generator Prompt **Version 1.0** **How to use:** Paste this entire document into the conversation in which you have finished planning your project. Attach the finalized `PLAN.md`, architecture, or other authoritative files if they are not already available there. You do not need to fill in a template first: the model is instructed to recover the project details from that conversation. **Expected result:** A downloadable, project-specific ZIP of bootstrap **inputs**. Extract it into a new temporary directory and start a capable tool-using coding agent there. The extracted root `AGENTS.md` will direct that bootstrap agent to create and validate the separate coding and strategic workspaces, then stop before operational activation. This prompt defines a reusable Concentrated OAP implementation profile. It is not itself the generated project's `AGENTS.md`, and it is not permission to implement or deploy the product immediately. --- ## 1. Your task in this planning conversation Use the established project context in this conversation to produce a **complete, self-contained Concentrated OAP bootstrap-input package** for this project. The planning phase is complete enough to prepare the handoff. Do not restart product discovery, substitute a different product, or ask me to repeat decisions already present in the conversation. Read available attached files when their exact contents are needed; do not reconstruct an existing finalized document from memory. Your deliverable is an actual downloadable archive named: ```text -concentrated-oap-bootstrap-inputs.zip ``` It must extract directly into a temporary directory with `AGENTS.md` at the archive root, **without an extra enclosing project directory**. The package must instruct a later, powerful coding agent to do the installation and scaffold generation. That bootstrap agent will run in a **third directory**, separate from both operational workspaces. It must create actual directories, populate them with substantive project-specific governance and detailed work-order drafts, implement and test the orchestration helpers, and write a truthful installation receipt. Distinguish these stages throughout the package: | Stage | Actor | Required result | Not authorized merely by this prompt | |---|---|---|---| | Package design | You, in this planning conversation | The complete project-specific bootstrap-input ZIP | Operating my machine, activating OAP, implementing the product, publishing a repository, or deploying anything | | Bootstrap materialization | Tool-using bootstrap agent in the extracted temporary directory | Populated coding and strategic workspaces, implemented and tested OAP helpers, inactive drafts, validation receipt | Starting operational agents, executing product orders, or crossing protected external boundaries | | Governed development | Strategic agent and coding agent in their separate workspaces | Bounded implementation, PRs, evidence, strategic review, authorized development merges | Human adjudication, unauthorized exposure, or production release | | Closure and release | Independent audit followed by accountable human judgment | Architecture-based milestone evidence and separately authorized release/deployment | Self-certification by the development loop | **Do not return only a plan, a file tree, or empty templates.** Generate the complete input documents needed by the bootstrap agent. It is acceptable for that agent to implement the orchestration helpers later; it is not acceptable to omit their contracts and acceptance tests and leave their design to improvisation. If file creation is genuinely unavailable in this chat, say so and provide the complete file contents with paths instead. Never invent a download link or claim that an archive exists without creating it. ## 2. Recover the project agreement and preserve source fidelity ### 2.1 Determine what has actually been decided Extract from this conversation and its attachments: - Project name, reasonable filesystem slug, purpose, intended users, and target workflows. - Agreed MVP and later milestones, explicit non-goals, and postponed work. - Accepted architecture, stack, interfaces, data flows, trust boundaries, and constraints. - Existing repository and remote, if actually specified; existing versus new project status. - Known runtime environment, protected services, permitted test resources, and recovery expectations. - Model/provider/client choices for the bootstrap, strategic, coding, and audit roles, **only if explicitly selected**. - Product-runtime models or providers, where applicable; do not confuse these with the agents used to develop the product. - Security, privacy, data, dependency, licensing, network, cost, and release restrictions. - Acceptance criteria and evidence requirements, including which numerical values are targets rather than measured results. - Material unresolved questions and prerequisites for activation. Distinguish **explicit human decisions**, **source-supported facts**, **proposed engineering defaults**, **unverified runtime assumptions**, and **unresolved authority questions**. Do not turn a conversational suggestion into an allegedly approved requirement. Resolve routine, reversible bootstrap details with sensible defaults and record them. Do not stop for questions already answered or for choices such as a private log-directory name. Where missing information affects product meaning, irreversible actions, or a non-delegable boundary, identify it precisely, keep that action blocked, and complete the safe independent parts of the package. ### 2.2 Preserve finalized documents If a finalized plan file exists, include it as `PLAN.md` **without changing its bytes**. A rename is not permission to summarize, translate, reformat, or silently improve it. Verify equality against the actual input file. If no finalized file exists, synthesize a complete standalone `PLAN.md` from the settled conversation. Preserve decisions and exclusions, identify unresolved matters, and label newly synthesized material honestly. Do not claim byte identity or prior human approval for a document you have just authored. Apply the same rule to an existing approved `ARCHITECTURE.md`. If there is no complete architecture document, author one from the established plan as described in §4. Distinguish agreed design from your proposed implementation elaboration. When finalized sources conflict, cite the conflicting clauses in `SOURCE-MAP.md`. Do not silently rewrite either source or invent permission to override a human decision. Block only the dependent actions that cannot safely proceed. Bootstrap generation does not authorize creative redesign of a protected architecture. ### 2.3 Use sources without making the package depend on this chat Use supplied Concentrated OAP documentation as the primary process basis. Ordinary OAP supplies the underlying role, evidence, runtime, and continuity discipline; Concentrated OAP supplies the explicit extensions for HWP/HJP/DHA, delegated development merge, D0/D1/D2, and Independent Closure Audit. Where both chapters are available, preserve complete snapshots under: ```text sources/concentrated-oap.md sources/oap.md ``` Do not fabricate source files or claim to have read a linked page that was not retrieved. If the full chapters are unavailable, this prompt supplies a self-contained minimum operational profile; record the absent snapshots and include the applicable requirements in the generated specifications. The bootstrap must not depend on an inaccessible URL, missing archive, another chat, or an unstated prior example. Include only project source material that is necessary and permitted for the handoff. Do not bundle entire private transcripts, credentials, personal information, customer data, or copyrighted material without the required authority. When redaction is necessary, distinguish the sanitized derivative from the original; do not falsely claim byte identity. `SOURCE-MAP.md` must distinguish: 1. Human-owned product decisions and their sources. 2. Concentrated OAP doctrine. 3. Concrete implementation-profile choices made by this prompt, such as the minimal role router, FIFO transport, and report-publication convention. 4. Project-specific defaults, deviations, assumptions, and unresolved prerequisites. Do not present the implementation profile as the only possible OAP implementation. ## 3. Required bootstrap-input archive At minimum, produce this package: ```text AGENTS.md INSTRUCTIONS.md PLAN.md ARCHITECTURE.md CRITICAL.md README.md SOURCE-MAP.md PACKAGE-MANIFEST.json INPUTS.sha256 PACKAGE-CHECKS.md specifications/ ROLE-CONTEXT.md OAP-PROTOCOL.md WORK-PROGRAM.md BOOTSTRAP-ACCEPTANCE.md sources/ ``` Additional small documents are welcome when they remove ambiguity. Do not create a speculative orchestration platform, unnecessary dependency stack, or dozens of redundant governance files. A full bootstrap means complete contracts and proof, not maximum file count. The documents have distinct jobs: | File | Required purpose | |---|---| | Root `AGENTS.md` | Constitution **only for the bootstrap-generating agent** running in the extracted temporary directory | | `INSTRUCTIONS.md` | Exact materialization procedure, destinations, inventory, file authorship/copying rules, helpers, tests, safe reruns, and stop condition | | `PLAN.md` | Standalone product agreement, preserved exactly when supplied as a finalized file | | `ARCHITECTURE.md` | Complete canonical product architecture, not merely OAP machinery | | `CRITICAL.md` | Canonical empty DHA register seed for a new project, or faithfully preserved existing register for an existing project | | `ROLE-CONTEXT.md` | Root routing, full strategic constitution, dense coding projections, source coverage, loading, context budgets, and synchronization | | `OAP-PROTOCOL.md` | Exact roles, publication, PR, transport, reporting, DHA, recovery, and review contracts | | `WORK-PROGRAM.md` | Project-specific objectives, dependencies, criteria, and instructions to expand every seed into a detailed inert draft | | `BOOTSTRAP-ACCEPTANCE.md` | Executable tests and inspections the bootstrap agent must implement and actually run | | `SOURCE-MAP.md` | Source relationships, preserved agreements, explicit defaults, and unresolved prerequisites | | Manifest/checksums | Verifiable package inventory, file sizes, digests, and source identities without circular hashes | | `PACKAGE-CHECKS.md` | Checks you actually ran on this input package, clearly separated from future installation and product tests | | `README.md` | Extraction instructions, initial bootstrap prompt, destinations, expected result, and separate activation steps | Every document must be useful for this specific project. Do not merely replace a project name in generic prose while leaving the architecture, work program, and acceptance criteria unspecified. ## 4. Produce a real Human Work Preloading package The bootstrap must result in a substantive HWP package, not only two agent launch scripts. The full `ARCHITECTURE.md` must explain the project's actual: - Purpose, system boundary, users, supported workflows, and non-goals. - Components, responsibility allocation, interfaces, and data/control flows. - Data ownership, persistence, lifecycle, concurrency, consistency, and recovery where relevant. - Security and trust boundaries, authentication/authorization, privacy, protected data, and dependency policy. - Runtime/deployment topology, resources, configuration, external dependencies, and failure behavior. - Observability, diagnostics, installation, operational recovery, and upgrade concerns appropriate to the milestone. - Verification strategy and the real boundaries that must be exercised. - Milestone definitions, observable acceptance criteria, and honestly unproven assumptions. - Design rationale and controlled evolution of the accepted architecture. Assign stable IDs to non-negotiable product requirements and architectural invariants. Use them in work orders and closure audits. When the supplied architecture must remain byte-identical, create an external requirement index rather than editing the source to insert IDs. The materialized project must also include substantive `SECURITY.md`, `TESTING.md`, readiness definitions, a project-specific D0/D1/D2 policy, runtime constraints, a recovery protocol, a roadmap, initial work-order drafts, and audit templates. Existing human-owned scope is not replaced by generated roadmap coverage. If a requirement does not fit the current milestone, record its approved deferral or the unresolved scope question. Do not silently drop it. ## 5. Three directories and four different `AGENTS.md` roles The bootstrap operates on three distinct directories: ```text BOOTSTRAP_ROOT = actual extracted temporary input directory REPO_ROOT = coding repository/workspace STRATEGIC_HOME = separate strategic workspace ``` Unless this conversation already specifies destinations, use these **proposed local defaults**: ```text REPO_ROOT=$HOME/codex-work/ STRATEGIC_HOME=$HOME/codex-supervision/ ``` Permit explicit operator overrides, for example `OAP_REPO_ROOT` and `OAP_STRATEGIC_HOME`. Resolve canonical paths, existing parents, symlinks, and collisions. Require the three directories to be distinct and non-nested. Never use the planning chat's artifact directory as a target-machine path. There must be four intentionally different instruction files: ```text BOOTSTRAP_ROOT/AGENTS.md Bootstrap-generator constitution; generates and validates, then stops. REPO_ROOT/AGENTS.md Minimal operational role router; not a full constitution. REPO_ROOT/oap/coding-instructions/AGENTS.md Purposefully distilled, extremely dense coding-agent constitution. STRATEGIC_HOME/AGENTS.md Full strategic-agent constitution. ``` The versioned source for the full strategic constitution must live at: ```text REPO_ROOT/oap/strategic-instructions/AGENTS.md ``` The private strategic copy is a controlled installation of that source, not an independently diverging authority. **Never copy the bootstrap `AGENTS.md` into either operational role.** If preserving it for provenance, name its archive copy `BOOTSTRAP-GENERATOR.md` so it cannot accidentally become inherited operational instructions. ### 5.1 Root repository router Keep the repository-root `AGENTS.md` tiny. It should only establish routing, retain role identity, and handle missing/conflicting roles. It must not contain the full product architecture, history, roadmap, or complete OAP protocol. Its behavior must be equivalent to: ```text Use the explicit launcher/human-assigned role. CODING: Read oap/coding-instructions/AGENTS.md and its compact ordered read set. Execute only the activated order. Never merge. STRATEGIC: Retain STRATEGIC_HOME/AGENTS.md as your full constitution. Repository inspection does not change your role to coding. UNKNOWN OR CONFLICTING ROLE: No operational mutation; reconcile the role first. Reading another role's instructions does not grant that role or its authority. ``` Launchers must set an explicit role marker and a short model-visible startup prompt, as well as the correct initial working directory. Do not assume an environment variable is automatically visible to the model. Role markers are routing aids, **not authentication or a security sandbox**. A temporary `cd`, a larger context window, or possession of a repository credential does not confer strategic or human authority. Bootstrap and audit roles have their own explicit scopes and cannot accidentally become operational roles by inspecting the repository. ### 5.2 Coding constitution: dense operational law, not a pleasant summary Generate the full strategic law and architectural requirement map first, then deliberately compile the coding projection. Human readability is secondary to compact, unambiguous execution. Use stable clause IDs, precise short clauses, and a defined notation where helpful. Remove rationale, repeated examples, product history, marketing, roadmap narrative, and strategic deliberation. Preserve every executor-relevant obligation, including its: ```text authority scope MUST / MUST NOT / NEVER strength conditions and exceptions ordering failure behavior verification requirement escalation boundary ``` Dense does not mean cryptic, lossy, encoded, or truncated. Never weaken a prohibition or omit an exception merely to save tokens. Do not turn the coding agent into an architect, roadmap owner, merge authority, or human adjudicator. ### 5.3 Strategic constitution: full control-plane law The strategic `AGENTS.md` must be complete and deliberately authored for the long-lived strategic role. It must not be the coding constitution with a different role name, and it must not be another compressed-only edition. Include architecture stewardship, delegated evolution, work-order authorship, provenance, D0/D1/D2, forced D1 decisions, the five-condition CRITICAL threshold, review and merge duties, combined risk, readiness, human authority, logical continuity, handoffs, diagnostic discipline, and ICA. Use readable explanations where they materially affect judgment. Do not pad it with entire source books or duplicate every byte-level procedure already specified in the strategic communication document. ### 5.4 Full architecture and compact architecture Keep one canonical current full `ARCHITECTURE.md` in the repository. Generate: ```text ARCHITECTURE-for-agents.md ``` as a dense executor projection with source revision/hash and mapped invariant IDs. Normal coding turns load the compact version, not the full architecture. Strategy and ICA use the full architecture. The compact edition is operationally sufficient for its declared scope but cannot override its source. A genuine gap goes to strategy for a bounded clarification, corrected projection, or explicitly authorized relevant source-section read. It must not trigger a habitual full-document dump into the short coding context. Do not keep independent editable full architecture, plan, or CRITICAL copies in the strategic workspace. Provide canonical-path references and revision identities instead. Immutable bootstrap snapshots remain clearly historical. ## 6. Context loading, distillation evidence, and drift control ### 6.1 Required read sets Normal coding startup or recovery: ```text minimal root router -> dense coding constitution -> compact architecture -> compact coding communication contract -> exact active work order -> relevant security/testing/subtree contracts -> only explicitly needed supporting excerpts ``` Do not routinely inject the full plan, full architecture, full strategic constitution, source OAP chapters, whole roadmap, future drafts, distillation map, or historical CRITICAL register into coding context. No wildcard or indirect mandatory link chain may quietly reintroduce them. Strategic startup or a new incarnation of that logical role: ```text full strategic constitution -> full strategic communication and initialization -> canonical full plan and architecture -> roadmap, decision policy, readiness and runtime references -> current CRITICAL register -> active order/report/review and current remote state -> relevant process doctrine and projection audit evidence ``` Full sources are initial or relevant reads, not necessarily repeated every turn. Refresh on changes, compaction, uncertainty, and relevant decision boundaries. `CRITICAL.md` is **not an always-loaded instruction file**. Strategy reads it at startup, at related dilemmas, during aggregate risk review, and before applicable gates. Coding reads it only for an ordered exact append or relevant cross-reference. A small state summary can be routine; the full history should not be. Inspect the installed agent client's real instruction-discovery behavior. Links do not necessarily auto-load, and nested `AGENTS.md` files may be inherited. Scope guards must ensure that an executor inspecting strategic-source files remains an executor. Do not overwrite unrelated global or ancestor instructions to make this appear to work. ### 6.2 Distillation map Require the bootstrap agent to generate: ```text oap/governance/DISTILLATION-MAP.md oap/governance/CONTEXT-BUDGET.md oap/governance/MANIFEST.json ``` The distillation map must connect source path/revision/section and normative obligation to the corresponding compact clause. Each source obligation is either preserved for coding or explicitly marked not executor-applicable with a reason. Map architecture invariants, authority boundaries, conditions, exceptions, and failure paths, not merely occurrences of the word `MUST`. The bootstrap agent must conduct and record a deliberate semantic comparison. Mechanical validators can check hashes, IDs, references, coverage declarations, and sizes. **They cannot prove semantic equivalence, the truth of D1 classification, or human authorization.** A generator's second review pass is not an independent audit. ### 6.3 Measure the transitive context cost Specify project-appropriate budgets. A reasonable default profile is: | Component | Target model tokens | UTF-8 byte ceiling | |---|---:|---:| | Root router | 400 | 2,048 | | Dense coding constitution | 2,200 | 12,000 | | Compact architecture | 3,800 | 20,000 | | Compact coding communication | 1,800 | 10,000 | | Complete routine coding governance read set, excluding order and code | 10,000 | 50,000 | These are implementation-profile defaults, **not OAP doctrine or a reason to discard law**. Measure all mandatory transitive reads, including relevant always-required security/testing material. If coverage cannot fit, redistill, restructure, or explicitly justify a revised budget; never silently truncate. Record exact bytes. Record exact tokens only with an identified appropriate tokenizer. Otherwise use `UNMEASURED` for tokens; do not present character-based estimates as exact counts. ### 6.4 Keep integrity domains separate Separate immutable input-source checksums, current canonical/projection hashes, installed-copy identities, and changing runtime/register state. Avoid self-referential manifest hashes. A legitimate CRITICAL append must not fail because the live register no longer equals its original seed. Check history/prefix integrity and authorized changes instead. Conversely, changing an expected hash does not authorize changing the governing source. For a governance-changing PR, validate against the accepted base and explicit ordered change scope. After acceptance, refresh strategic installed copies at a quiescent checkpoint, preserving private drafts/configuration/history. Refuse silent source/projection drift. ## 7. Concentrated OAP decision and authority rules Encode these rules in the full strategic constitution, compact executor duties, work-order templates, review checks, and readiness tooling. ### 7.1 Authority and durable truth Human authority covers product meaning, domain truth, risk appetite, non-delegable boundaries, human adjudication, final milestone judgment, and release/deployment authorization. Strategy owns delegated development planning, architecture evolution within the approved design space, work orders, investigation, provisional decisions, evidence review, and conditional development merge. Coding owns bounded implementation, allowed local setup, tests, documentation, PR publication, and truthful reports. It never merges, enables auto-merge, assigns itself the next objective, or invents human approval. Distinguish authority from evidence: ```text Remote repository/PR/CI = software and publication truth. Versioned orders/reports/active state = orchestration truth. Local runtime and private metadata = reconstructable execution state. FIFO or other notification = synchronization only. Model memory and report prose = claims, not authority. ``` ### 7.2 D0, D1, and D2 | Class | Required behavior | |---|---| | D0: ordinary delegated engineering | Decide, verify, document normally, continue. | | D1: consequential but safely containable provisional judgment | Strategy investigates, compares alternatives, chooses, mitigates, tests, orders a complete CRITICAL entry, and continues inside the delegated boundary. | | D2: non-delegable boundary | Analyze and recommend; do not cross the real boundary without explicit human authorization. Safe isolated preparation may continue if authorized. | A difficult reversible decision is not permission to halt the loop merely because human ownership would be more comfortable. Missing evidence requires a bounded investigation; ordinary bugs and failed tests require repair, not automatic CRITICAL entries. Production actions, irreversible real-data changes, credential operations, unapproved sensitive-data processing, public exposure, unresolved legal obligations, and changes to human-owned product meaning are typical D2 boundaries. Tailor them to this project's real environment. Never use D1 registration to grant rights, accept unknown licensing, disable mandatory controls, or waive a D2 boundary. ### 7.3 Two separate gates The strategic development merge gate requires the exact order to be satisfied, coherent scope, meaningful evidence, all required current-head CI successful, honest documentation, no secrets/prohibited artifacts, no D2 crossing, complete D1 registration, adequate reversibility, and a serious strongest-reason-not-to-merge assessment. Strategic merge means **accepted for continued development**, not human-approved for exposure or production. Before enabling delegated merge, inspect whether merging triggers deployment or another consequential external action. A development-merge delegation does not authorize an automatic D2 side effect. The human target gate requires applicable DHA clearance, verified conditions/remediation, truthful target-scope claims, and separate explicit deployment/release authorization. Passing tests, ICA, or a CRITICAL parser is not that authorization. ## 8. Exact CRITICAL/DHA contract ### 8.1 Admission: all five conditions A new `CRIT-NNNN` entry is allowed only when: 1. Existing human instructions, constitution, architecture, active order, and available evidence do not resolve the issue. 2. Strategy has investigated enough to identify materially different alternatives and must choose one. 3. A wrong choice could materially affect security, authorization, privacy, data integrity, irreversible loss, trust boundaries, exposure, deployment safety, or release acceptability. 4. One provisional option can be implemented and tested safely without crossing a non-delegable external or production boundary. 5. A competent human could plausibly reject or materially change the choice before the declared gate. Exclude routine bugs, failed tests, TODOs, known limitations, ordinary dependency choices, refactoring, style, speculative unsupported risks, low-impact reversible trade-offs, and duplicate entries for the same dilemma. For a new project, the seed contains policy and **zero real entries**. Put examples in clearly fenced templates or separate files. For an existing project, preserve the actual register and outstanding gates; never reseed it to empty. ### 8.2 Required entry template Include this complete structure, adapting only project-specific fields and explanatory guidance: ```markdown ## CRIT-0001 — Short decision title - **Status:** OPEN — HUMAN ADJUDICATION REQUIRED - **Introduced by:** - **Category:** security | authorization | data integrity | privacy | operations | architecture | dependency | other - **Severity:** low | medium | high | critical - **Decision confidence:** low | medium | high - **Required human gate:** - **Affected components:** ... ### Dilemma ... ### Decision taken ... ### Reasoning ... ### Alternatives considered ... ### Strongest argument that this decision is wrong ... ### Assumptions ... ### Failure mode and blast radius ... ### Mitigations and evidence ... ### Reversibility and rollback ... ### Safe autonomous continuation ### Exact human gate ### Exact question for the human adjudicator ... ### Strategic attestation ALL FIVE CRITICAL-ENTRY CONDITIONS SATISFIED ### Human disposition PENDING — append separately; do not edit this entry. ### Resolution PENDING — cleared only by the latest appended human ACCEPTED disposition. ``` These placeholders belong in a template, never a finalized real entry. ### 8.3 Every finalized work order declares the outcome Require exactly one declaration: ```markdown ## Deferred human adjudication - Decision: NONE ``` or: ```markdown ## Deferred human adjudication - Decision: APPEND CRIT-0001 ``` `NONE` is the normal case and needs no defensive essay. An `APPEND` order must contain the complete exact strategic-authored payload, stable identifier, byte extraction/hash convention, and all-five-conditions attestation. The publisher must reject missing or structurally incomplete declarations. Strategy owns admission, the provisional decision, ID, and exact entry wording. Coding may report an evidence-backed candidate but may append only the exact ordered bytes. It cannot invent, rewrite, weaken, close, or adjudicate the entry. Use a narrow tested append helper. Preserve all earlier bytes, detect duplicate IDs, lock concurrent updates, validate the trusted prior state, and handle safe retries without duplicate appends. Put CRITICAL changes in implementation commits **before** capturing the implementation head, never in the final report-only commit. Do not invent an as-yet unknown PR number. Where necessary, establish the safe prerequisite PR first and finalize the exact entry through a same-PR continuation before accepting the provisional decision for development merge. Specify evidence-only/mitigation appends to existing entries separately from admission of a new entry. They preserve historical wording and cannot clear a gate. ### 8.4 Human adjudication is appended and attributable The only allowed human disposition values are: ```text ACCEPTED REJECTED CHANGE REQUIRED DEFERRED ``` Provide this separate template: ```markdown ## HUMAN ADJUDICATION — CRIT-0001 — YYYY-MM-DD - Decision: ACCEPTED - Authority: - Conditions or required follow-up: - Evidence/reference: ``` Only the latest **attributable human** `ACCEPTED` disposition clears that entry's registered gate. The other three values remain blocking. Mitigation, a superseding implementation, or an agent's confidence does not close the original judgment. A human-looking Markdown name is not proof of human authorization. Keep the human recording path separate from agent append permissions and state the provenance check required by the project. If provenance is not established, report it as unverified and do not clear the real gate. Acceptance for one scope does not authorize unrelated exposure or substitute for the separate deployment decision. If material work remains, the disposition should be `CHANGE REQUIRED` or `DEFERRED`, not a falsely unconditional `ACCEPTED`. ## 9. Project-specific work program and order provenance Derive the work program from the actual plan and architecture. Do not mechanically produce an arbitrary number of objectives. A substantial project may need dozens; a small project needs fewer. Never create filler merely to reach a count. Make each objective a coherent, reviewable, proof-sized change. Where practical, aim for a bounded coding episode rather than a whole subsystem; estimated scope is not a guaranteed execution time. A task must include its own tests, documentation, and evidence rather than postpone all validation to the end. For every objective, specify: ```text ID and descriptive title Milestone and prerequisites Durable provenance references Relevant architecture/requirement IDs Goal and observable result Files or boundaries to inspect Bounded implementation scope Explicit non-goals and protected resources Numbered acceptance criteria Named verification commands or precisely specified tests to create Negative paths and the actual boundary under test Documentation requirements D0/D1/D2 considerations and human gates Expected PR mode and reporting obligations ``` Use Concentrated OAP provenance markers: ```text H = explicit human instruction or preload A = architecture, constitution, contract, or roadmap E = observed failing evidence I = independent audit finding C = CRITICAL/DHA remediation ``` Every final order needs at least one concrete source/section/evidence reference, not a bare letter. Include dependencies, criterion coverage, milestone gates, and ICA requests. Future drafts must be visibly `DRAFT UNTIL STRATEGIC RECONCILIATION`; unknown future SHAs, PRs, runtime measurements, and results remain unknown. Strategy must inspect current remote and runtime facts before finalizing a draft. Do not require execution of obsolete drafts after evidence changes the plan. Every accepted requirement must remain implemented, explicitly deferred by the appropriate authority, or openly unproven; it cannot disappear because the queue was revised. The work-program specification in this input ZIP may contain detailed seeds. The bootstrap agent must expand **every seed** into a substantive standalone inactive work-order draft. Repeated generic text with only the title changed is not completion. ## 10. Concrete reference protocol for the generated harness Use this tested-contract design unless the conversation already selected a different compatible transport or repository profile. This is a concrete implementation choice, not a claim that OAP requires these exact filenames or bytes. The default assumes a shared POSIX filesystem, such as Linux or an appropriate WSL environment. If the actual environment differs, explicitly define and test the adaptation or mark the runtime prerequisite. Do not pretend local named pipes work across unrelated hosts. ### 10.1 State and ownership ```text REPO_ROOT/oap/orders/-.md REPO_ROOT/oap/reports/-.md REPO_ROOT/oap/active REPO_ROOT/CRITICAL.md STRATEGIC_HOME/control.fifo STRATEGIC_HOME/response.fifo ``` At successful new bootstrap, `oap/active` is **absent**. Absence means inactive. An existing empty or malformed pointer is an error, not an alternative inactive state. For this profile, the active pointer contains exactly one valid order ID plus one LF. Select work only by that ID and a unique matching immutable order. Never infer work from newest/highest filename, timestamp, or directory order. Strategy owns order text and active-pointer publication. Coding commits their exact authorized bytes with the objective work; it does not rewrite them. Published orders and reports are immutable. The current pointer may change through authorized publication; its history remains preserved. ### 10.2 Objective and PR identity Default grammar and round progression: ```text ID: ^[0-9]{3}-[a-z]{1,2}$ rounds: a, b, ..., z, aa, ab, ..., az, ba, ..., zz NNN-a: create one objective branch and one PR later suffixes: amend that same branch and PR ``` Use the defined progression, not lexicographic sorting. Exhaustion requires a deliberate protocol revision, not silent renumbering. A process/context/model/provider/machine restart does not change objective or suffix. An interrupted `a` that already opened its PR resumes that PR. New strategic requirements after review get the next corrective suffix. Coding never chooses its next ID or creates a second PR for the same objective. Advance to a new objective only after verified acceptance/merge, or an explicitly recorded abandonment with dependency reassessment. An abandoned objective is not accepted work. ### 10.3 Publication and signaling `publish_order.py` must validate final status, metadata, provenance, source identities, transitions, PR mode, DHA declaration, and absence of genuine unresolved finalization fields. It must support a real no-write dry run. Publish the immutable order first, then atomically replace the active pointer, under a publication lock. These are **two recoverable writes**, not one magical atomic transaction. Signal only after both are valid. An interrupted identical unresolved publication may be completed safely; a completed historical order must not be reactivated. Notifications use exactly ASCII bytes `OK` (`4f 4b`), with **no newline**, order ID, status, or JSON. Handle partial I/O, EOF, invalid framing, and interruption. The sender closes its descriptor. A FIFO is a wake-up mechanism, not durable truth or authenticated authority. The coding wrapper consumes the control notification exactly once, checks durable state, and then starts one fresh coding invocation. The model must not wait for the already consumed signal again. Idle waiting is outside the model; there must be no periodic model calls simply to check for work. ### 10.4 PR before report; final report-only commit The normal coding sequence is: 1. Read the compact governance and exact active order; reconcile remote/local state. 2. Implement, verify, document, and perform any exact ordered CRITICAL append. 3. Commit and push the non-report work, including authorized order/active bytes. 4. Create or amend the correct PR **before composing the final report**. 5. Inspect and fix safe in-scope CI problems; push all remaining implementation changes. 6. Record the literal full implementation head commit ID. 7. Write the immutable matching report and commit **only that report**, with the implementation head as its first parent. 8. Push and verify remote PR identity, head, report bytes, parent, and report-only changed-path invariant. 9. Make no further mutation/push for that round; send response `OK` and exit. Use: ```text Implementation head SHA: Report publication commit: SELF ``` `SELF` resolves to the report-containing commit. Do not invent a commit's own hash before it exists. Validate object IDs according to the repository's actual object format. The report must separate observed implementation-head CI from later report-head CI. It cannot truthfully claim that its own future push or future checks were already verified. Post-publication verification belongs in private execution receipts and strategic review, not a rewrite of the published report. A truthful `PARTIAL`, `BLOCKED`, or `FAILED` report can notify strategy once properly published. Publication failure must not emit a misleading completion notification; retain evidence for recovery. ### 10.5 Strategic review Strategy independently checks the PR, all corrective rounds, implementation/report commits, actual diff, meaningful tests, documentation, outstanding judgments, and every required check at the current reviewed head. Use expected-head protection when supported; a changed head requires renewed review. Green CI is necessary but insufficient. Reports are evidence indexes, not acceptance. Missing, pending, cancelled, skipped, and unexecuted checks are not successful checks. Only strategy may perform an authorized development merge. Verify the remote merged state afterward. Preserve report-publication evidence even when the chosen merge method changes the commit graph on the default branch. ## 11. Materialized workspace inventory Require the bootstrap agent to create a coherent inventory equivalent to the following. Adapt only genuinely project-specific documents and client-specific filenames; keep the roles and authority boundaries intact. ```text REPO_ROOT/ AGENTS.md # minimal role router PLAN.md ARCHITECTURE.md ARCHITECTURE-for-agents.md CRITICAL.md OAP-COMMUNICATION-coding-agent.md # compact execution protocol README.md STATUS.md SECURITY.md TESTING.md .gitignore docs/ OAP-RUNBOOK.md AGENT-ROLE-SETUP.md READINESS.md DECISION-POLICY.md RUNTIME-CONSTRAINTS.md BOOTSTRAP-SOURCES.md bootstrap/ # immutable reference snapshots BOOTSTRAP-GENERATOR.md oap/ README.md RECOVERY.md COMPLETENESS.md # requirement-based; no fictional passes bootstrap-sources.lock.json runtime.env.example coding-instructions/ AGENTS.md # dense executor projection strategic-instructions/ AGENTS.md # full versioned strategic source OAP-COMMUNICATION-strategic.md strategic_model_init_material.md INITIAL-ROADMAP.md initial-orders/ governance/ MANIFEST.json DISTILLATION-MAP.md CONTEXT-BUDGET.md templates/ WORK-ORDER-TEMPLATE.md REPORT-TEMPLATE.md STRATEGIC-REVIEW-CHECKLIST.md CRITICAL-ENTRY-TEMPLATE.md HUMAN-ADJUDICATION-TEMPLATE.md HANDOFF-TEMPLATE.md audit/ ICA-PROTOCOL.md ICA-REQUEST-TEMPLATE.md ICA-REPORT-TEMPLATE.md ICA-REQUIREMENT-MATRIX-TEMPLATE.md requests/ # project milestone audit drafts prompts/ coding-round.md strategic-start.md ica-start.md bin/ bootstrap-two-agent-oap.sh doctor.sh check_governance.py check_state.py publish_order.py append_critical.py verify_report.py oap_fifo.py check_ica.py launch-coding-agent.sh launch-strategic-agent.sh launch-setup-tmux.sh launch-oap-tmux.sh orders/ # no activated order at new bootstrap reports/ # no fabricated execution reports tests/ oap/ # actual bootstrap/helper tests STRATEGIC_HOME/ AGENTS.md # controlled full strategic copy OAP-COMMUNICATION-strategic.md strategic_model_init_material.md INITIAL-ROADMAP.md SOURCE-REFERENCES.md # canonical product/register references RUNTIME.md runtime.env # private; activation disabled control.fifo response.fifo drafts/ critical-drafts/ workorders/ EXECUTION_TIMINGS.md STRATEGIC-HANDOFF.md audit/ requests/ results/ logs/ bootstrap-backups/ agent-homes/ coding/ strategic/ ``` The helper names specify responsibilities; shared library code is encouraged to prevent divergent validation logic. Do not require redundant daemons or external databases to implement this local profile. For existing repositories, preserve actual code, history, reports, register entries, and active state. Do not overwrite operational state with new-project defaults. Conflicting or running installations require a scoped inactive migration/refresh plan, not destruction or silent adoption. ## 12. Bootstrap execution, configuration, and safety The generated bootstrap `AGENTS.md` and `INSTRUCTIONS.md` must require the later agent to **materialize and validate**, not return another plan or archive. It may implement bootstrap infrastructure and its tests. It must not execute product work orders, implement application features, download large product assets/models, call product inference services, start operational agents, or change protected infrastructure merely to validate the scaffold. ### 12.1 Filesystem and repository behavior Inspect existing paths, file types, ownership, inherited instructions, Git state, remote, dirty/untracked work, and prior manifests before writing. Support both `.git` directories and worktree `.git` files. Require no-write dry runs, atomic scoped writes, identical no-op reruns, and explicit backup-preserving refreshes. Never reset, clean, stash, force-push, replace unrelated files, broadly change permissions, or follow unsafe symlinks for convenience. A missing remote must not prevent safe local scaffold generation. Do not invent an owner/URL/visibility, create a remote, commit or publish the real scaffold, open PRs, or change branch protection unless separately and explicitly authorized. Creating disposable Git fixtures for tests is different from publishing the real project. Use private permissions for runtime configuration and pipes, narrow generated-file manifests, correct quoting, and support for spaces/Unicode. Preserve original source bytes deliberately across tooling and line-ending configuration. ### 12.2 Client/model configuration Do not hardcode a contemporary model, API version, context size, pricing, or CLI flag from memory. Preserve explicit choices in the conversation; otherwise leave named activation prerequisites and discovery procedures. The bootstrap must inspect installed client/version/help/configuration behavior and use supported syntax. Separate client homes/configuration for coding and strategy. Do not copy authentication files, cookies, histories, or private global configurations between them. Configuration must distinguish bootstrap structure readiness, role-model/authentication readiness, remote publication readiness, and authorization to begin. No silent model/provider fallback. High autonomy means sufficient tools inside an explicitly approved runtime, not blanket permission on an ordinary host. Do not default to unrestricted execution, production credentials, broad host mounts, or disabling safety controls. Where a bounded high-autonomy profile is explicitly selected, document and gate it; local acknowledgement flags do not themselves establish human authority. ### 12.3 Separate setup from operation Generate a setup mode that opens two side-by-side terminal panes with the correct directories and role-specific homes. It must permit configuration/login work without activating an order or launching the autonomous loop. Missing models, remote, or authentication may be reported but must not prevent access to the setup shells. Generate a separate operational mode that checks the required configuration, governance, accepted baseline, runtime boundaries, remote policy, and explicit activation before starting roles. The coding process is fresh per activated round. The strategic role is logically persistent. Both launchers use tiny routing prompts rather than duplicated constitutions. Exiting an agent leaves the appropriate shell or stops the owned wrapper cleanly. Explicit quit must not trigger automatic resurrection. Prevent duplicate role processes and accidental double consumers. Do not kill or repurpose unrelated terminal sessions or services. Provide `--print-only`/dry-run behavior, appropriate `--help`, redacted errors, and bounded cleanup. Do not install cron, daemon, or automatic-start behavior by default. ## 13. Recovery is protocol, not improvisation Write a complete recovery protocol and test these cases: | Observation | Required recovery | |---|---| | No active order | Remain inactive or wait outside the model; do not invent work | | Control consumed; agent died; no final report | Reconcile and resume the same ID, branch, and PR at unfinished work | | Interrupted first round already created its PR | Reuse that verified PR; do not create another | | Final report pushed; response notification lost | Resume strategic review; do not rerun implementation | | Report exists locally but remote publication is unverified | Complete/verify publication without rewriting the report or claiming remote success prematurely | | Order published but pointer update interrupted | Recover only the identical unresolved transition, or preserve and report the conflict | | Duplicate notification | Inspect durable state; suppress repeated implementation | | Model/provider/context/machine replaced | Restore the same logical role and objective, not a new number or suffix | | CI pending | Wait/recheck evidence; do not create busywork or new corrective requirements merely for the delay | | User deliberately quits | Stop owned activity cleanly; no hidden auto-restart | Logical roles outlive individual processes. Private metadata supports recovery but cannot override repository/OAP truth. Diagnostic orders must identify the first reproducibly failing boundary and the smallest experiment that distinguishes plausible causes, with a stop condition. Do not change product code below a boundary the failing path has not reached. Preserve observations; supersede incorrect interpretations explicitly rather than rewriting old reports. ## 14. Independent Closure Audit and readiness ICA is mandatory before an architecture-defined milestone is accepted as complete. Finishing the roadmap or merging every planned PR does not certify the milestone. Provide a substantive project-derived requirement matrix, not only an empty generic table. Initially classify actual claims honestly; do not prefill implementation or test success from the plan. An ICA uses an independent human/auditor or a fresh isolated audit context. It begins with human milestone scope, full architecture, and the exact current merged product revision, not the strategist's completion narrative. Use these classifications: ```text IMPLEMENTED PARTIAL ABSENT UNPROVEN ``` Each row names the requirement, enforcing source/runtime path, applicable test/evidence, negative paths, limitations, and audited revision. Reports, README percentages, and PR summaries remain claims until substantiated. Require boundary-faithful evidence: real entry point, authority, routing, persistence, integration, or deployment path as appropriate. A mock replacing the boundary under test cannot prove that boundary. Record auditor/context provenance honestly. Structural validation does not prove independence or correctness. A new context can audit without becoming a third permanent operational lane, a coding agent, or a merge authority. Gaps create H/A/E/I/C-linked closure work. After remediation, repeat the architecture-to-current-main audit; a completed closure queue may still omit requirements. Tie evidence to the exact evaluated revision and require reassessment of relevant later changes. Separate development acceptance, demonstration capability, evidence confidence, judgment debt, target deployment permission, and final human milestone acceptance. Report functional completeness, uncertainty reduction, and technical-debt reduction separately where useful. Activity counts must not masquerade as functionality. ## 15. Bootstrap acceptance tests and truthful receipts The input package must require the bootstrap agent to implement and run executable tests, not only check that files exist. Use disposable Git repositories, fake agent executables, fake remote/CI transports, temporary named pipes, and isolated terminal sessions. Tests need finite timeouts, exact expected failures, and cleanup of only their own resources. Real model calls and production side effects are not bootstrap tests. At minimum, cover: | Area | Required proof | |---|---| | Inputs and source installation | Hash/byte fidelity, complete inventory, broken-link detection, preserved existing plan/architecture/register, no silent reseeding | | Path safety | Distinct non-nested roots, symlink/type/ownership errors, spaces/Unicode, valid worktrees, preservation of unrelated dirty/untracked files | | Reruns | True no-write dry run, identical no-op rerun, scoped explicit refresh with backups and private-state preservation | | Role routing | Correct coding/strategic routing, missing/conflicting-role refusal, bootstrap scope retained, cross-role source inspection does not switch authority | | Context | Small root router, genuinely dense coding law, full strategic law, correct transitive read sets, no wildcard loading, exact byte/token provenance | | Distillation/drift | Missing clause references, stale source/projection hashes, unauthorized source redefinition, accepted-versus-candidate handling, controlled installed-copy refresh | | Inactive state | No active pointer/order/signal for a new installation; malformed or empty pointer rejected; existing operational state not overwritten | | Order publication | Final schema/provenance/DHA validation, exact identity, immutable publication, legal transitions, partial-publication recovery | | PR/round continuity | Same-PR corrective rounds, interrupted first-round reuse, z-to-aa handling for this profile, duplicate detection, restart without renumbering | | FIFO and idle | Exact two-byte framing, partial I/O/EOF/error handling, one control consumer, zero model calls while idle, duplicate notification protection | | Reports | PR-before-report sequence, literal implementation parent, report-only SELF commit, remote verification distinguished from local checks, no invented future CI | | Critical register | Exact authorized appends, prior-history preservation, retries/concurrency, unique IDs, complete admission fields, no agent adjudication, fenced templates ignored | | Human gates | Four exact dispositions, latest-disposition semantics, unverified attribution remains blocking, scoped gates, no deployment authority inferred from acceptance alone | | Setup and launch | Correct panes/cwd/homes, setup works before credentials exist, missing activation prerequisites block operation, explicit quit respected, duplicate processes prevented | | Recovery | Consumed/lost signals, unfinished implementation, already-published report, local-only report, replacement process/model/provider, no replay | | Strategic acceptance | Required checks at exact reviewed head, missing/pending/cancelled checks block, changed head re-reviewed, merge side effects checked, remote merge verified | | ICA | Human-scope/architecture-derived matrix, exact revision/freshness, required classifications, no self-certification, repeat audit after remediation | | Privacy and cleanup | No credential/private-content leakage, no protected services touched, no real model invocation, cleanup limited to test-owned resources | Fake-client tests prove the configured invocation contract, not undocumented behavior of an installed real client. Record safe installed-client qualification separately. Use explicit `PASSED`, `FAILED`, `SKIPPED`, `NOT RUN`, `BLOCKED`, `PENDING`, or `MISSING` statuses; only actual successful execution is a pass. The bootstrap agent must write `BOOTSTRAP-RECEIPT.md` in `BOOTSTRAP_ROOT`, containing: ```text Actual resolved destinations and generation identity Input/source verification Created / identical / backed-up / conflicting files Canonical and derived governance identities Transitive read-set sizes and tokenizer provenance Semantic distillation review and its limitations Expanded objective inventory and requirement/dependency coverage Every required test: command, result, evidence, or precise limitation Actual installed-client qualification separately from fake tests Remote/model/authentication/runtime/authority activation prerequisites Preserved register state and zero new fabricated adjudications Proof that no operational activation or product work occurred Explicit remaining human review/configuration/activation steps ``` It must distinguish: ```text Input package checks Materialized bootstrap/helper verification Operational activation readiness Product/runtime qualification Product/milestone acceptance ``` A valid scaffold can still be blocked for activation. Do not claim the product works because orchestration tests pass. ## 16. Checks you must perform before delivering the ZIP These are **your** checks in this planning chat, separate from the bootstrap agent's future executable validation: 1. Read every generated input document and reconcile role names, paths, filenames, protocol choices, source relationships, and cross-references. 2. Confirm product architecture/work program are substantive and faithful to the settled plan; no missing feature is hidden by a polished checklist. 3. Confirm the archive-root `AGENTS.md` is bootstrap-only and requires actual materialization, validation, and an inactive stop. 4. Confirm the downstream repository root is specified as a tiny router, coding law is purposefully distilled, strategic law is full, and normal coding reads do not import full sources indirectly. 5. Verify the strict CRITICAL threshold, declarations, exact author/append roles, disposition values, deliberate loading, dual gates, and ICA requirements are consistent across all documents. 6. Confirm model/client/repository/runtime facts are supplied, verified where appropriate, or explicitly unconfigured; no credentials or invented approvals appear. 7. Verify finalized source bytes and record actual checksums. Keep immutable seed integrity separate from future authorized evolution. 8. Create a safe ZIP with relative paths, no traversal, no absolute paths, no unintended symlinks, no enclosing directory, and exactly one intended archive-root `AGENTS.md`. 9. Test extraction into a disposable directory. Verify extracted inventory, checksums, safe paths, and all required local links. Do not run bootstrap generation or activate agents as part of this extraction test. 10. Record only actual package checks in `PACKAGE-CHECKS.md`. Do not claim future helper tests, remote CI, independent audit, runtime installation, or product acceptance have already happened. If a check fails, fix the input package where safe. If a genuine authority/source gap remains, preserve it explicitly and ensure downstream actions fail safely rather than quietly inventing the missing fact. ## 17. Deliver the package with a minimal handoff Provide the downloadable ZIP and a brief explanation that it is the **input for a separate bootstrap agent**, not a preinstalled application. Give this initial bootstrap prompt, adapted only when necessary to match actual filenames: ```text Read AGENTS.md and execute INSTRUCTIONS.md. Use the bundled PLAN.md, ARCHITECTURE.md, CRITICAL.md, specifications, and available source documents. Materialize and validate the separate coding and strategic workspaces. Do not execute product orders or start operational agents. Stop before activation and write BOOTSTRAP-RECEIPT.md. ``` State the resolved proposed destination paths and any genuine unresolved activation prerequisites. Keep detailed setup inside the package. Do not print every document into the chat, require manual assembly of many files, or substitute a promise to produce the archive later. The final installed state required of the bootstrap agent is: > **Governance installed; coding and strategic roles separated; dense executor context verified; OAP helpers implemented and tested; detailed work drafts prepared; human gates preserved; no product work or operational activation performed.** --- ## Methodology references and interpretation This reusable prompt operationalizes the supplied OAP and Concentrated OAP methodology. Where source chapters are available, use and preserve them as described above. - [Orchestrated Agentic Programming](https://doc.slaif.si/storitve/orchestrated-agentic-programming/) - [Concentrated OAP](https://doc.slaif.si/storitve/orchestrated-agentic-programming/concentrated-oap/) The minimal repository role router, full-versus-distilled document topology, illustrative context budgets, local FIFO transport, extended lettered round IDs, and report-only `SELF` convention are the concrete bootstrap profile specified here. They implement the methodology; they are not assertions that the conceptual OAP chapters mandate these exact implementation details. The links are references, not substitutes for the self-contained package. Do not claim a current online comparison unless it was actually performed.