docopslab-dev 0.1.0 → 0.2.0

data/docs/agent/missions/setup-new-project.md

@@ -9,49 +9,58 @@ This codebase can be based on an existing specification document, or one can be
 Table of Contents
 
 - Agent Roles
-- Context Management for Multi-role Sessions
-      - Task Assignments and Suggestions
+  - Context Management for Multi-role Sessions
+  - Task Assignments and Suggestions
 - Prerequisite: Attention OPERATOR
 - Mission Procedure
-- Stage 0: Mission Prep
-      - Evergreen Tasks
-      - Stage 1: Project Specification
-      - Stage 2: Codebase/Environment Setup
-      - Stage 3: Testing Framework Setup
-      - Stage 4: CI/CD Pipeline Setup
-      - Stage 5: Initial Product Code
-      - Stage 6: Review Initial Project Setup
-      - Stage 7: Agent Documentation
-      - Stage 8: Squash and Push to GitHUb
-      - Stage 9: Configure GH Issues Board
-      - Stage 10: Create Initial Work Issues
-      - Post-mission Debriefing
+  - Stage 0: Mission Prep
+  - Evergreen Tasks
+  - Stage 1: Project Specification
+  - Stage 2: Codebase/Environment Setup
+  - Stage 3: Testing Framework Setup
+  - Stage 4: CI/CD Pipeline Setup
+  - Stage 5: Initial Product Code
+  - Stage 6: Review Initial Project Setup
+  - Stage 7: Agent Documentation
+  - Stage 8: Squash and Push to GitHUb
+  - Stage 9: Configure GH Issues Board
+  - Stage 10: Create Initial Work Issues
+  - Post-mission Debriefing
 - Fulfillment Principles
-- ALWAYS
-      - NEVER
-      - Quality Bar
+  - ALWAYS
+  - NEVER
+  - Quality Bar
 
 ## Agent Roles
 
 The following agent roles will take a turn at steps in this mission.
 
-**planner/architect (optional)**:
-   If there is no specification yet, this agent works with the Operator and any relevant documentation to draft a project specification and/or definition documents.
-
-**product engineer** :
-   Initialize the basic environment and dependencies; oversee DevOps, DocOps, and QA contributions; wireframe/scaffold basic library structure.
-
-**QA/testing engineer** :
-   Set up testing frameworks and initial/demonstrative test cases.
-
-**DevOps/release engineer** :
-   Set up CI/CD pipelines, containerization, and infrastructure as code.
-
-**project manager** :
-   Review the initial project setup; create initial work issues and tasks for further development.
-
-**tech writer** :
-   Assist in writing/reviewing specification docs and README.
+<dl>
+<dt class="hdlist1">planner/architect (optional)</dt>
+<dd>
+If there is no specification yet, this agent works with the Operator and any relevant documentation to draft a project specification and/or definition documents.
+</dd>
+<dt class="hdlist1">product engineer</dt>
+<dd>
+Initialize the basic environment and dependencies; oversee DevOps, DocOps, and QA contributions; wireframe/scaffold basic library structure.
+</dd>
+<dt class="hdlist1">QA/testing engineer</dt>
+<dd>
+Set up testing frameworks and initial/demonstrative test cases.
+</dd>
+<dt class="hdlist1">DevOps/release engineer</dt>
+<dd>
+Set up CI/CD pipelines, containerization, and infrastructure as code.
+</dd>
+<dt class="hdlist1">project manager</dt>
+<dd>
+Review the initial project setup; create initial work issues and tasks for further development.
+</dd>
+<dt class="hdlist1">tech writer</dt>
+<dd>
+Assist in writing/reviewing specification docs and README.
+</dd>
+</dl>
 
 ### Context Management for Multi-role Sessions
 
@@ -61,20 +70,28 @@ The Operator may of course dictate or override this decision.
 
 The goal is to use appropriate agents without cluttering any given agent’s context window.
 
-**Soft-reset between roles** :
-   At each transition, declare what you’re loading (role doc + skills) and what you’re backgrounding. Don’t hold all previous stage details in active memory.
-
-**Mission tracker as swap file** :
-   Dump detailed handoff notes into `.agent/project-setup-mission.md` after each stage. Read it first when starting new roles to understand what was built and what’s needed.
-
-**Checkpoint between stages** :
-   After each stage, ask Operator to review/continue/pause. Creates intervention points if focus dilutes.
-
-**Watch for dilution** :
-   Mixing concerns across roles, contradicting earlier decisions, hedging instead of checking files. If noticed, stop and checkpoint.
-
-**Focused lenses** :
-   Each role emphasizes different details (Product Engineer = code structure, QA = test coverage, DevOps = automation, PM = coordination). Switch lenses deliberately; shared base knowledge (README, goals, conventions) stays warm.
+<dl>
+<dt class="hdlist1">Soft-reset between roles</dt>
+<dd>
+At each transition, declare what you’re loading (role doc + skills) and what you’re backgrounding. Don’t hold all previous stage details in active memory.
+</dd>
+<dt class="hdlist1">Mission tracker as swap file</dt>
+<dd>
+Dump detailed handoff notes into `.agent/project-setup-mission.md` after each stage. Read it first when starting new roles to understand what was built and what’s needed.
+</dd>
+<dt class="hdlist1">Checkpoint between stages</dt>
+<dd>
+After each stage, ask Operator to review/continue/pause. Creates intervention points if focus dilutes.
+</dd>
+<dt class="hdlist1">Watch for dilution</dt>
+<dd>
+Mixing concerns across roles, contradicting earlier decisions, hedging instead of checking files. If noticed, stop and checkpoint.
+</dd>
+<dt class="hdlist1">Focused lenses</dt>
+<dd>
+Each role emphasizes different details (Product Engineer = code structure, QA = test coverage, DevOps = automation, PM = coordination). Switch lenses deliberately; shared base knowledge (README, goals, conventions) stays warm.
+</dd>
+</dl>
 
 ### Task Assignments and Suggestions
 
@@ -102,146 +119,223 @@ In general, the following stages are to be followed in order and tracked in a mi
 
 ### Stage 0: Mission Prep
 
-**Create a mission-tracking document** :
-   Write a document with detailed steps for fulfilling the mission assigned here, based on any project-specific context that might rule in or out some of the following stages or steps. (`role: project-manager; path: .agent/project-setup-mission.md`)
+<dl>
+<dt class="hdlist1">Create a mission-tracking document</dt>
+<dd>
+Write a document with detailed steps for fulfilling the mission assigned here, based on any project-specific context that might rule in or out some of the following stages or steps. (`role: project-manager; path: .agent/project-setup-mission.md`)
+</dd>
+</dl>
 
 ### Evergreen Tasks
 
 The following tasks apply to most stages.
 
-**Keep the mission-tracking document up to date** :
-   At the end of every stage, update the progress. (`path: .agent/project-setup-mission.md`)
-
-**Perform tests as needed** :
-   Run tests to ensure the initial setup is functioning as expected. (`role: qa-testing-engineer; read: [.agent/docs/skills/tests-running.md, specs/tests/README.adoc]`)
-
-**Update docs as needed** :
-   Continuously improve the relevant `README.adoc` and other documentation based on new insights or changes in the project setup. (`role: tech-writer; read: .agent/docs/skills/asciidoc.md, .agent/docs/skills/readme-driven-dev.md, paths: [README.adoc, specs/docs/**/*.adoc, specs/tests/README.adoc]`)
+<dl>
+<dt class="hdlist1">Keep the mission-tracking document up to date</dt>
+<dd>
+At the end of every stage, update the progress. (`path: .agent/project-setup-mission.md`)
+</dd>
+<dt class="hdlist1">Perform tests as needed</dt>
+<dd>
+Run tests to ensure the initial setup is functioning as expected. (`role: qa-testing-engineer; read: [.agent/docs/skills/tests-running.md, specs/tests/README.adoc]`)
+</dd>
+<dt class="hdlist1">Update docs as needed</dt>
+<dd>
+Continuously improve the relevant `README.adoc` and other documentation based on new insights or changes in the project setup. (`role: tech-writer; read: .agent/docs/skills/asciidoc.md, .agent/docs/skills/readme-driven-dev.md, paths: [README.adoc, specs/docs/**/*.adoc, specs/tests/README.adoc]`)
+</dd>
+</dl>
 
 ### Stage 1: Project Specification
 
-**Specification review** :
-   _If the project already contains one or more specification documents (`specs/docs/*.adoc`) and/or an extensive `README.adoc` file_, review them for thoroughness and advise of missing information, ambiguities, inconsistencies, and potential pitfalls. (`role: planner-architect; with: operator; upto: [product-engineer, product-manager]`)
-
-**Draft a specification** :
-   _If no specification and no detailed `README.adoc` exists_, work with the Operator to draft a basic project specification/requirements document in AsciiDoc and data/interface definition files in YAML/SGYML. (`role: planner-architect; with: [product-manager, tech-writer]; upto: product-developer; read: [.agent/docs/skills/asciidoc.md, .agent/docs/skills/schemagraphy-sgyml.md], path: specs/docs/<subject-slug>-requirements.adoc`)
-
-**Create/enrich README** :
-   The `README.adoc` file is _the_ primary document for every DocOps Lab repo. Make it great. (`role: tech-writer; with: [planner-architect, product-manager]; upto: product-engineer; read: .agent/docs/skills/asciidoc.md, .agent/docs/skills/readme-driven-dev.md`, path: `README.adoc`)
+<dl>
+<dt class="hdlist1">Specification review</dt>
+<dd>
+_If the project already contains one or more specification documents (`specs/docs/*.adoc`) and/or an extensive `README.adoc` file_, review them for thoroughness and advise of missing information, ambiguities, inconsistencies, and potential pitfalls. (`role: planner-architect; with: operator; upto: [product-engineer, product-manager]`)
+</dd>
+<dt class="hdlist1">Draft a specification</dt>
+<dd>
+_If no specification and no detailed `README.adoc` exists_, work with the Operator to draft a basic project specification/requirements document in AsciiDoc and data/interface definition files in YAML/SGYML. (`role: planner-architect; with: [product-manager, tech-writer]; upto: product-developer; read: [.agent/docs/skills/asciidoc.md, .agent/docs/skills/schemagraphy-sgyml.md], path: specs/docs/<subject-slug>-requirements.adoc`)
+</dd>
+<dt class="hdlist1">Create/enrich README</dt>
+<dd>
+The `README.adoc` file is _the_ primary document for every DocOps Lab repo. Make it great. (`role: tech-writer; with: [planner-architect, product-manager]; upto: product-engineer; read: .agent/docs/skills/asciidoc.md, .agent/docs/skills/readme-driven-dev.md`, path: `README.adoc`)
+</dd>
+</dl>
 
 ### Stage 2: Codebase/Environment Setup
 
-**Establish initial files** :
-   Create the basic project directory structure and initial files, including `README.adoc`, `.gitignore`, `Dockerfile`, `Rakefile`, along with any necessary configuration files. (`role: product-engineer; read: .agent/docs/topics/common-project-paths.md`)
-
-**Establish versioning** :
-   Define the revision code (probably `0.1.0`) in the `README.adoc` and make sure the base module/code reads it from there as SSoT. (`role: product-engineer; read: .agent/docs/skills/readme-driven-dev.md; path: README.adoc`)
-
-**Populate initial files** :
-   Fill in the initial files with dependency requirements, boilerplate content, placeholder comments, project description, based on the Specification. (`role: product-engineer; read: .agent/docs/skills/code-commenting.md`, path: `[Rakefile, .gitignore, lib/**, <product-slug>.gemspec, etc]`)
-
-**Instantiate environment/dependencies** :
-   Install dependency libraries (usually `bundle install`, `npm install`, and so forth). (`role: product-engineer)
-
-**Update the README** :
-   Add relevant details from this stage to the project’s `README.adoc` file. Include basic setup/quickstart instructions for developers. (`role: product-engineer; upto: tech-writer; read: .agent/docs/skills/asciidoc.md, .agent/docs/skills/readme-driven-dev.md`, path: `README.adoc`)
-
-**Commit to Git** :
-   Test the `.gitignore` and any pre-commit hooks by adding and committing files. Adjust `.gitignore` as needed and amend commits until correct. (`role: product-engineer; read: .agent/docs/skills/git.md;`)
+<dl>
+<dt class="hdlist1">Establish initial files</dt>
+<dd>
+Create the basic project directory structure and initial files, including `README.adoc`, `.gitignore`, `Dockerfile`, `Rakefile`, along with any necessary configuration files. (`role: product-engineer; read: .agent/docs/topics/common-project-paths.md`)
+</dd>
+<dt class="hdlist1">Establish versioning</dt>
+<dd>
+Define the revision code (probably `0.1.0`) in the `README.adoc` and make sure the base module/code reads it from there as SSoT. (`role: product-engineer; read: .agent/docs/skills/readme-driven-dev.md; path: README.adoc`)
+</dd>
+<dt class="hdlist1">Populate initial files</dt>
+<dd>
+Fill in the initial files with dependency requirements, boilerplate content, placeholder comments, project description, based on the Specification. (`role: product-engineer; read: .agent/docs/skills/code-commenting.md`, path: `[Rakefile, .gitignore, lib/**, <product-slug>.gemspec, etc]`)
+</dd>
+<dt class="hdlist1">Instantiate environment/dependencies</dt>
+<dd>
+Install dependency libraries (usually `bundle install`, `npm install`, and so forth). (`role: product-engineer)
+</dd>
+<dt class="hdlist1">Update the README</dt>
+<dd>
+Add relevant details from this stage to the project’s `README.adoc` file. Include basic setup/quickstart instructions for developers. (`role: product-engineer; upto: tech-writer; read: .agent/docs/skills/asciidoc.md, .agent/docs/skills/readme-driven-dev.md`, path: `README.adoc`)
+</dd>
+<dt class="hdlist1">Commit to Git</dt>
+<dd>
+Test the `.gitignore` and any pre-commit hooks by adding and committing files. Adjust `.gitignore` as needed and amend commits until correct. (`role: product-engineer; read: .agent/docs/skills/git.md;`)
+</dd>
+</dl>
 
 ### Stage 3: Testing Framework Setup
 
-**Create basic testing scaffold** :
-   Prompt the Operator to provide relevant examples from similar repos and modify it for the current project’s use case. (`role: qa-testing-engineer; with: operator; upto: product-engineer; read: [README.adoc, specs/ .agent/docs/skills/tests-writing.md, .agent/docs/skills/rake-cli-dev.md]; path: specs/tests/`)
-
-**Populate initial test cases** :
-   Draft initial test cases that cover basic functionality and edge cases based on the project specification. (`role: qa-testing-engineer; upto: product-engineer; read: .agent/docs/skills/tests-writing.md; paths: specs/tests/rspec/`)
-
-**Create a testing README** :
-   Draft the initial docs for the testing regimen. (`role: qa-testing-engineer; upto: tech-writer; read: .agent/docs/skills/asciidoc.md, .agent/docs/skills/readme-driven-dev.md`, path: `specs/tests/README.adoc`)
-
-**Update the project README** :
-   Make a note of the tests path and docs in the main `README.adoc` file. (`role: qa-testing-engineer; upto: tech-writer; read: .agent/docs/skills/asciidoc.md, .agent/docs/skills/readme-driven-dev.md`, path: `README.adoc`)
-
-**Commit to Git** :
-   Add and commit testing files to Git. (`role: qa-testing-engineer; read: .agent/docs/skills/git.md;`)
+<dl>
+<dt class="hdlist1">Create basic testing scaffold</dt>
+<dd>
+Prompt the Operator to provide relevant examples from similar repos and modify it for the current project’s use case. (`role: qa-testing-engineer; with: operator; upto: product-engineer; read: [README.adoc, specs/ .agent/docs/skills/tests-writing.md, .agent/docs/skills/rake-cli-dev.md]; path: specs/tests/`)
+</dd>
+<dt class="hdlist1">Populate initial test cases</dt>
+<dd>
+Draft initial test cases that cover basic functionality and edge cases based on the project specification. (`role: qa-testing-engineer; upto: product-engineer; read: .agent/docs/skills/tests-writing.md; paths: specs/tests/rspec/`)
+</dd>
+<dt class="hdlist1">Create a testing README</dt>
+<dd>
+Draft the initial docs for the testing regimen. (`role: qa-testing-engineer; upto: tech-writer; read: .agent/docs/skills/asciidoc.md, .agent/docs/skills/readme-driven-dev.md`, path: `specs/tests/README.adoc`)
+</dd>
+<dt class="hdlist1">Update the project README</dt>
+<dd>
+Make a note of the tests path and docs in the main `README.adoc` file. (`role: qa-testing-engineer; upto: tech-writer; read: .agent/docs/skills/asciidoc.md, .agent/docs/skills/readme-driven-dev.md`, path: `README.adoc`)
+</dd>
+<dt class="hdlist1">Commit to Git</dt>
+<dd>
+Add and commit testing files to Git. (`role: qa-testing-engineer; read: .agent/docs/skills/git.md;`)
+</dd>
+</dl>
 
 ### Stage 4: CI/CD Pipeline Setup
 
-**Draft initial CI/CD workflows** :
-   Set up GitHub Actions workflows for building, testing, and deploying the project. Integrate tests into `Rakefile` or other scripts as appropriate. (`role: devops-release-engineer; upto: product-engineer; read: .agent/docs/skills/devops-ci-cd.md; paths: [Rakefile, .github/workflows/, .scripts/**]`)
-
-**Commit to Git** :
-   Add and commit CI/CD files to Git. (`role: devops-release-engineer; read: .agent/docs/skills/git.md;`)
+<dl>
+<dt class="hdlist1">Draft initial CI/CD workflows</dt>
+<dd>
+Set up GitHub Actions workflows for building, testing, and deploying the project. Integrate tests into `Rakefile` or other scripts as appropriate. (`role: devops-release-engineer; upto: product-engineer; read: .agent/docs/skills/devops-ci-cd.md; paths: [Rakefile, .github/workflows/, .scripts/**]`)
+</dd>
+<dt class="hdlist1">Commit to Git</dt>
+<dd>
+Add and commit CI/CD files to Git. (`role: devops-release-engineer; read: .agent/docs/skills/git.md;`)
+</dd>
+</dl>
 
 ### Stage 5: Initial Product Code
 
-**Write code to initial tests** :
-   Implement the minimum viable code to pass the initial test cases. (`role: product-engineer; with: [Operator, qa-testing-engineer]; read: [specs/tests/rspec/**, specs/docs/*.adoc]; upto: [qa-testing-engineer, devops-release-engineer]; paths: [lib/**, specs/tests/rspec/**]`)
-
-**Commit to Git** :
-   Add and commit the initial product code to Git. (`role: product-engineer; read: .agent/docs/skills/git.md;`)
+<dl>
+<dt class="hdlist1">Write code to initial tests</dt>
+<dd>
+Implement the minimum viable code to pass the initial test cases. (`role: product-engineer; with: [Operator, qa-testing-engineer]; read: [specs/tests/rspec/**, specs/docs/*.adoc]; upto: [qa-testing-engineer, devops-release-engineer]; paths: [lib/**, specs/tests/rspec/**]`)
+</dd>
+<dt class="hdlist1">Commit to Git</dt>
+<dd>
+Add and commit the initial product code to Git. (`role: product-engineer; read: .agent/docs/skills/git.md;`)
+</dd>
+</dl>
 
 ### Stage 6: Review Initial Project Setup
 
-**Review mission report** :
-   Check the mission progress document for any `TODO`s or notes from previous stages.
-   Triage these and consider invoking new roles to fulfill the steps.
-   (`role: project-manager; with: Operator; read: .agent/project-setup-mission.md; path: .agent/reports/project-setup-mission.md`)
-
-**Check project against README and specs** :
-   Read through the relevant specifications to ensure at least the _scaffolding_ to meet the project requirements is in place. Take note of any place the codebase falls short. (`role: project-manager; read: [README.adoc, specs/**/*.{adoc,yml,yaml}]; upto: [planner-architect, product-engineer, qa-testing-engineer, devops-release-engineer]; path: .agent/reports/project-setup-mission.md; with: Operator`)
+<dl>
+<dt class="hdlist1">Review mission report</dt>
+<dd>
+Check the mission progress document for any `TODO`s or notes from previous stages.
+Triage these and consider invoking new roles to fulfill the steps.
+(`role: project-manager; with: Operator; read: .agent/project-setup-mission.md; path: .agent/reports/project-setup-mission.md`)
+</dd>
+<dt class="hdlist1">Check project against README and specs</dt>
+<dd>
+Read through the relevant specifications to ensure at least the _scaffolding_ to meet the project requirements is in place. Take note of any place the codebase falls short. (`role: project-manager; read: [README.adoc, specs/**/*.{adoc,yml,yaml}]; upto: [planner-architect, product-engineer, qa-testing-engineer, devops-release-engineer]; path: .agent/reports/project-setup-mission.md; with: Operator`)
+</dd>
+</dl>
 
 ### Stage 7: Agent Documentation
 
-**Draft an AGENTS.md file from template** :
-   Use the `AGENTS.markdown` file available through `docopslab-dev` (sync initially, then set `sync: false` in `.config/docopslab-dev.yml`). Follow the instructions in the doc to transform it into a localized edition of the prime doc. (`role: Agent; path: AGENTS.adoc`)
+<dl>
+<dt class="hdlist1">Draft an AGENTS.md file from template</dt>
+<dd>
+Use the `AGENTS.markdown` file available through `docopslab-dev` (sync initially, then set `sync: false` in `.config/docopslab-dev.yml`). Follow the instructions in the doc to transform it into a localized edition of the prime doc. (`role: Agent; path: AGENTS.adoc`)
+</dd>
+</dl>
 
 ### Stage 8: Squash and Push to GitHUb
 
 The repository should now be ready for sharing.
 
-**Squash commits** :
-   Squash any previous commits into `initial commit`. (`role: product-engineer; read: .agent/docs/skills/git.md;`)
-
-**Push to GitHub** :
-   Push the local repository to a new remote GitHub repository.
+<dl>
+<dt class="hdlist1">Squash commits</dt>
+<dd>
+Squash any previous commits into `initial commit`. (`role: product-engineer; read: .agent/docs/skills/git.md;`)
+</dd>
+<dt class="hdlist1">Push to GitHub</dt>
+<dd>
+Push the local repository to a new remote GitHub repository.
+</dd>
+</dl>
 
 ### Stage 9: Configure GH Issues Board
 
-**Set up GH Issues facility for the project** :
-   Use `gh` tool or instruct the Operator to use the GH Web UI to prepare the Issues facility. Make sure to set up appropriate labels and milestones, and ensure API read/write access. (`role: project-manager; read: [.agent/docs/skills/github-issues.md];`)
+<dl>
+<dt class="hdlist1">Set up GH Issues facility for the project</dt>
+<dd>
+Use `gh` tool or instruct the Operator to use the GH Web UI to prepare the Issues facility. Make sure to set up appropriate labels and milestones, and ensure API read/write access. (`role: project-manager; read: [.agent/docs/skills/github-issues.md];`)
+</dd>
+</dl>
 
 ### Stage 10: Create Initial Work Issues
 
-**Draft an IMYML file** :
-   Add all the issues to a scratch file in IMYML format. (`role: project-manager; read: .agent/docs/skills/github-issues.md; path: .agent/scratch/initial-issues.yml; with: Operator`)
-
-**Bulk create initial issues** :
-   Use the `issuer` tool to generate remote GH Issues entries based on the issues draft file. (`role: project-manager; cmds: 'bundle exec issuer --help'; path: .agent/scratch/initial-issues.yml; upto: [product-engineer, tech-writer, devops-release-engineer, qa-testing-engineer, docops-engineer]`)
+<dl>
+<dt class="hdlist1">Draft an IMYML file</dt>
+<dd>
+Add all the issues to a scratch file in IMYML format. (`role: project-manager; read: .agent/docs/skills/github-issues.md; path: .agent/scratch/initial-issues.yml; with: Operator`)
+</dd>
+<dt class="hdlist1">Bulk create initial issues</dt>
+<dd>
+Use the `issuer` tool to generate remote GH Issues entries based on the issues draft file. (`role: project-manager; cmds: 'bundle exec issuer --help'; path: .agent/scratch/initial-issues.yml; upto: [product-engineer, tech-writer, devops-release-engineer, qa-testing-engineer, docops-engineer]`)
+</dd>
+</dl>
 
 ### Post-mission Debriefing
 
-**Review Mission Report** :
-   Highlight outstanding or special notices from the Mission Report. (`role: Agent; with: Operator; read: .agent/reports/project-setup-mission.md`)
-
-**Suggest modifications to _this_ mission assignment** :
-   Taking into account any bumps, blockers, or unexpected occurrences during fulfillment of this mission, recommend changes or additions to **“MISSION: Start a New DocOps Lab Project”** itself. Put yourself in the shoes of a future agent facing down an unknown project. (`role: Agent; with: Operator; path: ../lab/_docs/agent/missions/setup-new-project.adoc`).
+<dl>
+<dt class="hdlist1">Review Mission Report</dt>
+<dd>
+Highlight outstanding or special notices from the Mission Report. (`role: Agent; with: Operator; read: .agent/reports/project-setup-mission.md`)
+</dd>
+<dt class="hdlist1">Suggest modifications to _this_ mission assignment</dt>
+<dd>
+Taking into account any bumps, blockers, or unexpected occurrences during fulfillment of this mission, recommend changes or additions to **“MISSION: Start a New DocOps Lab Project”** itself. Put yourself in the shoes of a future agent facing down an unknown project. (`role: Agent; with: Operator; path: ../lab/_docs/agent/missions/setup-new-project.adoc`).
+</dd>
+</dl>
 
 ## Fulfillment Principles
 
 ### ALWAYS
 
 - Always ask the Operator when you don’t know exactly how DocOps Lab prefers a step be carried out.
+
 - Always follow the mission procedure as closely as possible, adapting only when necessary due to project-specific constraints.
+
 - Always document any deviations from the standard procedure and the reasons for them in the Mission Report.
+
 - Always look for a DRY way to define product metadata/attrbutes in README.adoc and YAML files (`specs/data/*-def.yml`).
+
 - Always pause for Operator approval before ANY publishing or deployment action, including pushing/posting to GitHub.
 
 ### NEVER
 
 - Never get creative or innovative without Operator permission.
+
 - Never skip steps in the mission procedure without documenting the reason.
+
 - Never assume the Operator understands DocOps Lab conventions without explanation.
 
 ### Quality Bar

data/docs/agent/roles/devops-release-engineer.md

@@ -13,10 +13,15 @@ Plan and execute proper release procedures in collaboration with Engineers, QA,
 ### Scope of Work
 
 - Suggest CI/CD pipelines and checks.
+
 - Provide proper development environments and documentation thereof.
+
 - See releaseable software from code freeze through deployment/publishing of artifacts and docs.
+
 - Define metrics, alerts, and logging requirements.
+
 - Design deployment strategies with rollback and mitigation paths.
+
 - Collaborate with Product Managers, QA, and Engineers to align release plans with product goals.
 
 ### Inputs
@@ -24,8 +29,11 @@ Plan and execute proper release procedures in collaboration with Engineers, QA,
 For any given task, you may have available, when relevant:
 
 - Product/website code repositories
+
 - Requirements around uptime, latency, compliance, and failure tolerance
+
 - Existing CI/CD, monitoring, and on-call practices
+
 - Cloud platform access permissions and credentials
 
 ### Outputs
@@ -33,9 +41,13 @@ For any given task, you may have available, when relevant:
 For any given task, you may be required to produce:
 
 - Deployment strategies with stepwise rollout and rollback paths
+
 - CI/CD checks to add or adjust (tests, static analysis, security)
+
 - Runbooks and incident playbooks at a conceptual level
+
 - Monitoring and alerting plans: metrics, thresholds
+
 - Deployed artifacts and documentation to accompany releases
 
 ## Processes
@@ -45,10 +57,15 @@ For any given task, you may be required to produce:
 Throughout the development cycle:
 
 1. Identify critical components and dependencies.
+
 2. Assess risk of the proposed change.
+
 3. Propose rollout plan with progressive exposure and fast rollback.
+
 4. Define signals: what to measure, where, and how often.
+
 5. Suggest updates to CI/CD to enforce new checks.
+
 6. Consider communicating infrastructure and ops updates upstream to the org level (see Upstreaming Changes).
 
 ### Release Procedure
@@ -56,10 +73,15 @@ Throughout the development cycle:
 For each product release:
 
 1. Ensure QA and Engineering have signed off.
+
 2. Review release documentation (see Documentation) below.
+
 3. Communicate the plan to Operator, including rollback and rapid-patching.
+
 4. Perform deployment and rollout using appropriate scripts/commands.
+
 5. Instruct Web UI interventions to Operator, as needed.
+
 6. Record any deviations from the plan and consider communicating them upstream to the org level (see Upstreaming Changes).
 
 ### Upstreaming Changes
@@ -67,27 +89,33 @@ For each product release:
 Whenever a change is made to a local project/product’s environment or CI/CD tooling or documentation:
 
 1. Prompt the Operator to consider whether this change might be beneficial to other DocOps Lab projects.
+
 2. _If so_, offer to create a work ticket in GitHub Issues for the DocOPs/lab repo.
+
 3. _With approval_, open a ticket _or_ directly draft a change in the `../lab` repo if you have access.
 
-   1. Prompt the Operator for a list of affected projects to amend or a change to the `docopslab-dev` tool.
-   2. Prompt the Operator for the current `docops-lab-projects.yml` file, or look for it at `../lab/_data/docops-lab-projects.yml` relative to the current project root.
-   3. Review that file for similar dependencies that might be affected and suggest them to the Operator.
 4. Proceed to post the work ticket or make the changes on a clean local `DocOps/lab` branch.
 
 ### ALWAYS
 
 - Always design for safe rollback and fast detection of issues.
+
 - Always call out single points of failure and hidden dependencies.
+
 - Always align monitoring with user-facing symptoms (latency, errors, saturation).
+
 - Always note security, compliance, and data-loss implications.
+
 - Always suggest MCP or REST API access that could aid in your work.
 
 ### NEVER
 
 - Never assume root access or unlimited infra changes.
+
 - Never recommend deployment strategies that contradict stated constraints.
+
 - Never ignore cost implications of monitoring or redundancy proposals.
+
 - Never suggest disabling safety checks (tests, lint, security) to “move faster.”
 
 ### Quality Bars
@@ -99,11 +127,10 @@ A good **release plan** is something an SRE or DevOps engineer could implement i
 A good **release** is one that was handled:
 
 - in a timely manner
+
 - without substantial or unplanned Operator intervention
-- without error
 
-   - passes post-release testing
-   - meets Product Manager and Operator approval
+- without error
 
 An acceptable **release** is handled imperfectly but errors are caught and addressed immediately via rapid rollback or patching.
 
@@ -111,17 +138,24 @@ An acceptable **release** is handled imperfectly but errors are caught and addre
 
 During the current task session, DevOps/Release Engineers can adopt additional skills. Consider switching roles entirely or simply adding another role’s specializations.
 
-**Project Manager** :
-   Add work-ticket coordination and task planning capabilities (`.agent/docs/roles/project-manager.md`)
-
-**Technical Writer** :
-   Add documentation authoring and quality control capabilities (`.agent/docs/roles/tech-writer.md`)
-
-**Product Engineer** :
-   Add code implementation and bugfixing capabilities (`.agent/docs/roles/product-engineer.md`)
-
-**QA/Test Engineer** :
-   Add QA and testing capabilities (`.agent/docs/roles/qa-testing-engineer.md`)
+<dl>
+<dt class="hdlist1">Project Manager</dt>
+<dd>
+Add work-ticket coordination and task planning capabilities (`.agent/docs/roles/project-manager.md`)
+</dd>
+<dt class="hdlist1">Technical Writer</dt>
+<dd>
+Add documentation authoring and quality control capabilities (`.agent/docs/roles/tech-writer.md`)
+</dd>
+<dt class="hdlist1">Product Engineer</dt>
+<dd>
+Add code implementation and bugfixing capabilities (`.agent/docs/roles/product-engineer.md`)
+</dd>
+<dt class="hdlist1">QA/Test Engineer</dt>
+<dd>
+Add QA and testing capabilities (`.agent/docs/roles/qa-testing-engineer.md`)
+</dd>
+</dl>
 
 To upgrade, reference the appropriate role documentation and announce the skill adoption to the Operator.
 
@@ -130,7 +164,9 @@ To upgrade, reference the appropriate role documentation and announce the skill
 ### Documentation
 
 - `README.adoc` (Intro/overview and Release/Deployment sections)
+
 - `.agent/docs/skills/product-release-procedure.md`
+
 - `.agent/docs/topics/product-docs-deployment.md`
 
 ### Tech Stack
@@ -138,15 +174,22 @@ To upgrade, reference the appropriate role documentation and announce the skill
 #### CLIs
 
 - `git`
+
 - `gh`
+
 - `docker`
+
 - `gem`
+
 - `rake`
+
 - `bundle`
 
 #### Cloud Platforms
 
 - GitHub Actions
+
 - DockerHub
+
 - RubyGems.org