@doxbrix/doxloop 0.1.0

package/skills/doxloop-authoring/references/screenshots.md

@@ -0,0 +1,251 @@
+# Application guide screenshots
+
+Use this workflow only for screenshots of the product being documented. The
+existing `doxloop capture` command inspects external documentation design
+references and is not part of this workflow.
+
+## Decide whether capture is enabled
+
+Capture application screenshots when any of these conditions applies:
+
+- the task prompt says screenshots are required because `--screenshots` was
+  supplied;
+- the user explicitly asks to include, create, capture, or refresh screenshots;
+- `.doxloop/project.json` sets `application.screenshots.policy` to `auto` and
+  the agreed page is a visible user-interface workflow.
+
+Do not capture when the task prompt disables screenshots; when the project
+policy is `off` and the task prompt does not explicitly require them; when the
+request mentions screenshots only negatively or as an example; or when the page
+has no meaningful visible application state. An explicit `--screenshots`
+requirement overrides project policy for that run. Never add screenshots to API
+or CLI procedures merely for decoration.
+
+## Use the user-managed application
+
+Assume the user has already started and prepared the application. Never start,
+restart, stop, seed, reset, or reconfigure it. Never run a project startup,
+setup, database, or authentication command. Use `application.baseUrl` when it
+is configured; otherwise use the application URL supplied by the user or
+already open in the approved in-app browser. If no reachable application
+surface is available, finish the text guide without broken image links and
+report that screenshots could not be captured.
+
+Capture only the agreed application origin and its required public assets.
+Never use a real customer or production environment, change shared data, or
+operate outside the workflow being documented.
+
+## Reuse in-app browser authentication
+
+Keep authentication in the in-app browser controlled by Codex, Claude, or the
+selected agent. Do not add authentication settings to `.doxloop/project.json`
+and do not create login scripts, storage-state files, credential files, or
+environment-variable requirements.
+
+1. Open the application in the approved in-app browser and inspect the visible
+   state.
+2. If an authenticated application page is already visible, reuse that session
+   and continue without mentioning login.
+3. If the application redirects to login, first allow the browser's existing
+   session or password-manager autofill to work. The agent may select a sign-in
+   control after autofill, but must never inspect, copy, reveal, or log an
+   autofilled value.
+4. If user interaction is required, keep the login page open and ask the user
+   once to complete login, MFA, SSO, passkey, or browser confirmation directly
+   in that browser. Never ask for a password, token, OTP, cookie, recovery code,
+   or secret in chat.
+5. After login, verify a stable authenticated state such as the expected page,
+   account menu, workspace name, or application heading before capture.
+6. Keep the same browser session and context for the entire capture manifest.
+   Do not clear cookies, local storage, cache, or site data and do not open the
+   workflow in an isolated browser context.
+7. If the session expires, preserve the current manifest row, return to the
+   login checkpoint once, verify authentication again, and resume that row
+   rather than restarting or taking screenshots of the login page.
+
+Use a demo, test, or other non-production account with synthetic data. Treat
+login and account-selection screens as private operational states: exclude
+them from the guide unless the agreed reader task is specifically about login.
+
+## Plan the visual story
+
+Finish and fact-check the ordered text procedure before operating the
+application. Make every UI step atomic: one primary reader action followed by
+one observable result. Do not capture while improvising the guide.
+
+Create a capture manifest before taking the first image. Give every published
+UI step a stable step ID, including steps that intentionally have no image:
+
+| Step ID | Published action | Expected visible state | Capture? | Target | Filename | Alt text | Status |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| 01 | Open **Team settings**. | Team settings page is visible. | yes | page heading | `01-team-settings.png` | Team settings page with the heading marked as step 1 | planned |
+| 02 | Copy the workspace ID. | ID is copied; no durable visual change. | no | — | — | — | text-only |
+| 03 | Select **Invite member**. | Invitation form is open. | yes | Invite member button | `03-invite-form.png` | Invitation form opened from the Invite member button marked as step 3 | planned |
+
+The manifest is the source of truth for capture order, filenames, step marker
+numbers, alt text, and placement. Never choose screenshots opportunistically
+from whatever page happens to be open. Do not renumber captures to hide an
+intentionally text-only step: the image prefix and visual marker must match the
+published step number.
+
+For each guide step, record:
+
+1. the reader action immediately before the image;
+2. the stable visible state that proves the action succeeded;
+3. the control or region that needs attention, if any;
+4. the image filename, alternative text, and optional caption.
+
+When the user asks for a screenshot for every step, capture every step that has
+a meaningful visible UI state. Mark non-UI steps and actions with no durable
+visible change as `text-only` in the manifest and explain that decision in the
+completion summary. Otherwise capture only when an image reduces ambiguity or
+confirms an important state. Keep the application chrome and nearby labels when
+they help readers orient themselves. Prefer a viewport screenshot or a
+carefully cropped stable region; avoid very tall full-page screenshots for task
+steps.
+
+## Operate and verify the workflow
+
+Prefer stable accessible roles, labels, visible text, and product test IDs over
+fragile CSS structure. Reuse verified Playwright, Cypress, or other UI tests as
+workflow evidence when available, but do not modify or submit destructive
+production data. Process the manifest strictly from the lowest step ID to the
+highest. For each planned image:
+
+1. reset or establish the expected fixture state;
+2. perform the documented actions in their published order;
+3. wait for the expected visible outcome, not an arbitrary delay alone;
+4. dismiss only transient UI that a normal reader would not see;
+5. inspect the viewport for secrets, personal data, unstable timestamps,
+   unrelated notifications, and accidental browser content;
+6. add contextual highlighting when it materially helps;
+7. capture the image to its manifest filename;
+8. open the saved file and verify that it is the expected step, has the correct
+   marker, is legible, contains no sensitive or transient content, and is not a
+   duplicate of another step;
+9. mark the manifest row `verified` only after that inspection, then remove the
+   overlay and continue.
+
+If a capture is wrong, replace that file immediately and repeat the same
+manifest row. Do not continue and plan to sort screenshots out later. Do not
+reuse one screenshot for multiple steps unless those steps intentionally refer
+to exactly the same visible state and the prose makes that explicit.
+
+If browser automation is unavailable or the application cannot be reached,
+finish a complete text guide, do not create placeholder images or broken image
+links, and report the capture limitation.
+
+## Highlight the relevant context
+
+When `application.screenshots.highlight` is not `false`, highlight the control
+or result a reader should notice. Use a temporary browser overlay rather than
+editing product source or permanently changing application styles:
+
+- draw a 3 px high-contrast ring with 4–6 px clearance around the target;
+- add a small numbered marker matching the corresponding guide step;
+- optionally dim the rest of the viewport by no more than 18 percent;
+- keep the target, its label, validation message, and surrounding orientation
+  visible;
+- never use color alone: the numbered marker and nearby prose must identify the
+  target;
+- remove the overlay before continuing to the next application action.
+
+When the browser supports script evaluation, inject the packaged
+[highlight helper](../assets/screenshot-highlight.js), call
+`__doxloopScreenshotHighlight({ selector, step, dim })` immediately before the
+screenshot, and call `__doxloopRemoveScreenshotHighlight()` immediately after.
+Choose `selector` from a verified stable test ID, accessible label relationship,
+or other stable product evidence. The helper returns the measured target bounds
+for the capture record and never mutates product source.
+
+The ring and marker should be baked into the PNG so they work in every
+documentation generator. Do not draw arrows or labels over interactive text,
+form values, error details, or other information the reader needs.
+
+## Store and embed screenshots
+
+Follow the selected generator skill for its native public asset directory and
+image syntax. Group images under a stable guide-specific directory and use
+ordered, descriptive filenames, for example:
+
+```text
+assets/guides/invite-team-member/
+  01-team-settings.png
+  02-invite-form.png
+  03-invitation-sent.png
+```
+
+Use these default committed locations unless the existing project has an
+established equivalent:
+
+| Generator | Screenshot directory | Public/reference prefix |
+| --- | --- | --- |
+| Doxbrix | `<contentDir>/assets/guides/<guide>/` | `/assets/guides/<guide>/` |
+| Docusaurus | `static/img/guides/<guide>/` | `/img/guides/<guide>/` |
+| MkDocs | `docs/assets/guides/<guide>/` | page-relative `assets/guides/` |
+| Sphinx | `<contentDir>/_static/guides/<guide>/` | `/_static/guides/<guide>/` |
+| Hugo | `static/images/guides/<guide>/` | `/images/guides/<guide>/` |
+| VitePress | `docs/public/images/guides/<guide>/` | `/images/guides/<guide>/` |
+| Markdoc | `assets/guides/<guide>/` | `/assets/guides/<guide>/` |
+| Nextra | `public/images/guides/<guide>/` | `/images/guides/<guide>/` |
+| Starlight | `public/images/guides/<guide>/` | `/images/guides/<guide>/` |
+| Jekyll | `assets/images/guides/<guide>/` | `relative_url` from `/assets/images/guides/<guide>/` |
+| Static HTML | `site/assets/guides/<guide>/` | `/assets/guides/<guide>/` |
+
+Respect any configured base path when the generator requires relative or
+base-aware URLs. Verify the final built output contains each image; source-file
+existence alone is not sufficient.
+
+Guide screenshots are committed documentation assets. Never put them under
+`.doxloop/cache/reference/`. Embed each verified image before capturing the
+next step. Insert it inside the same ordered-list item, immediately after the
+instruction or expected-result sentence that the image proves. Do not collect
+step screenshots at the beginning or end of the guide, place an image between
+two unrelated steps, or let Markdown indentation terminate the ordered list.
+Add concise alternative text describing the useful visible state, not phrases
+such as "screenshot of". Use a caption for orientation or consequence that is
+not already obvious from the prose. Keep all essential instructions and values
+in text outside the image.
+
+For Doxbrix, prefer a captioned frame:
+
+```mdx
+<Frame caption="The highlighted Invite member control opens the invitation form.">
+
+![Team settings with the Invite member control marked as step 1](/assets/guides/invite-team-member/01-team-settings.png)
+
+</Frame>
+```
+
+Use native caption or figure syntax supplied by other generators. Plain
+Markdown images are the portable fallback.
+
+## Run the screenshot completeness gate
+
+Do not finish a screenshot-enabled guide until all of these checks pass:
+
+1. Compare the final ordered procedure with the manifest row by row.
+2. Confirm every published UI step has exactly one `verified` image or an
+   explicit `text-only` reason.
+3. Confirm every verified manifest filename exists exactly once in the guide
+   and immediately follows its matching step.
+4. Confirm the filename prefix, highlighted marker, prose step number, visible
+   state, and alt text all refer to the same step.
+5. Confirm there are no unreferenced captures, broken paths, duplicate images,
+   stale screenshots, or screenshot links outside the guide-specific folder.
+6. Build the selected generator, then inspect the rendered guide from top to
+   bottom at desktop and narrow widths. Verify list numbering, image order,
+   cropping, legibility, captions, and the association between each step and
+   image.
+
+Any mismatch is a blocking defect. Fix the procedure, manifest, capture, or
+placement and rerun the entire gate; do not report the guide as complete.
+
+## Refresh without churn
+
+During update, recapture only when the documented workflow, visible label,
+layout, theme, or expected outcome changed, or when the user explicitly asks.
+Preserve filenames when the semantic step is unchanged so links and review
+history remain stable. Remove an old image only after all page references to it
+are removed. Run `doxloop test` and the generator build to catch missing assets,
+then review the rendered guide at desktop and narrow widths.

package/skills/doxloop-authoring/references/template-routing.md

@@ -0,0 +1,94 @@
+# Expert template routing
+
+Use this reference after initial product discovery and before proposing coverage.
+Templates are investigation and authoring playbooks, never evidence about the
+configured product.
+
+## Compose the expertise profile
+
+Build one profile from:
+
+1. one primary domain template when evidence supports a meaningful match;
+2. at most one adjacent domain template when a distinct public capability needs
+   it;
+3. every documentation-type template needed for the agreed reader outcomes;
+4. audience flavor applied inside each selected domain/type combination; and
+5. the persisted brief and current user request.
+
+Do not treat audience as an independent documentation template. Audience changes
+depth, vocabulary, prerequisites, examples, risk emphasis, and navigation order
+inside a domain/type plan. When two audiences have materially different jobs,
+create separate journeys or sections instead of averaging them into vague copy.
+If no specialized domain matches, use the product evidence and relevant
+documentation-type playbooks without forcing a domain label.
+
+## Select without forcing a preset
+
+- Infer templates from configured source evidence, existing pages, the persisted
+  brief, and the user's words.
+- Do not ask the user to choose a template or know a template identifier.
+- When the match is clear, apply it and state the selected expertise profile in
+  the discovery summary.
+- When two choices would materially change scope, audience, or outcomes, include
+  that decision in the single consolidated consultation already required for
+  create work.
+- A named template in the request is a strong intent signal, not permission to
+  invent unsupported capabilities.
+- Preserve selected outcomes and audience decisions in the documentation brief;
+  do not persist template identifiers as permanent requirements.
+
+## Domain routing signals
+
+| Primary domain | Strong evidence signals |
+| --- | --- |
+| SaaS application | workspaces or tenants, memberships, roles, subscriptions, browser workflows |
+| API platform | public routes or specifications, credentials, request/response contracts, quotas |
+| Developer library | package exports, public types, runtime requirements, library contract tests |
+| CLI tool | command parser, help output, flags, stdout/stderr, exit contracts |
+| Payments and fintech | payment intents or charges, settlement, refunds, disputes, signed events |
+| E-commerce | catalog, cart, order, inventory, fulfillment, returns |
+| AI and machine learning | model or agent interfaces, inference, prompts, evaluations, model limits |
+| Data platform | connectors, schemas, pipelines, transformations, lineage, data quality |
+| Security and identity | identities, authentication factors, authorization policy, audit events |
+| Infrastructure and DevOps | provisioning, environments, deployment, health, observability, recovery |
+
+Choose the most specific supported domain. For example, a payment API uses the
+payments domain as primary and the API-platform domain as adjacent. A SaaS
+product with ordinary REST endpoints remains SaaS-primary unless developers are
+the confirmed primary readers and the API is the main product.
+
+## Documentation-type routing signals
+
+| Type playbook | Select when readers need to |
+| --- | --- |
+| Getting started | reach a first meaningful result from a clean state |
+| Developer portal | integrate across onboarding, concepts, tasks, and reference |
+| API reference | look up a supported programmatic contract consistently |
+| SDK guide | install and use a language library correctly |
+| CLI manual | discover and automate supported commands and options |
+| User guide | complete recurring product tasks through a UI or user-facing workflow |
+| Administrator guide | configure shared settings, identities, roles, policy, or lifecycle |
+| Integration guide | connect the product to another bounded system |
+| Deployment and operations | deploy, observe, maintain, upgrade, and recover a running system |
+| Troubleshooting knowledge base | diagnose observable symptoms and apply verified recovery |
+| Migration and release | move between versions or act on release-visible change |
+| Architecture and concepts | make correct decisions using stable public mental models |
+
+Read only the selected domain and documentation-type files. Do not load the
+whole catalog merely because it exists.
+
+## Resolve overlap
+
+- Domain templates own domain risk, lifecycle, state, and practitioner concerns.
+- Type templates own reader journey, page architecture, procedural contract,
+  and reference completeness.
+- The audience-flavor reference owns adaptation within the selected combination.
+- The navigation-architecture reference owns the common site frame, type-block
+  composition, domain overlays, audience ordering, and navigation quality gate.
+- The generator skill owns syntax, components, navigation files, and rendering.
+- Product evidence overrides every template suggestion.
+
+If a suggested topic has no reader need or supporting evidence, omit it. If
+source evidence reveals a material capability not named by a template, document
+it according to the agreed scope rather than constraining coverage to the
+template.

package/skills/doxloop-authoring/references/type-administrator-guide.md

@@ -0,0 +1,59 @@
+# Administrator-guide playbook
+
+Use when readers configure shared scope, identities, access, policy, lifecycle,
+or organization-wide behavior.
+
+## Separate authority from ordinary use
+
+Define administrator roles, delegated authority, managed scope, and boundaries
+before procedures. Separate initial setup, routine administration, governance,
+security, billing, lifecycle, and recovery when the product supports them.
+
+## Expected coverage
+
+- administrative access and safe first setup;
+- organization, workspace, project, or environment lifecycle;
+- member onboarding, offboarding, ownership, roles, and permissions;
+- authentication, federation, credentials, and session policy;
+- defaults, inheritance, precedence, propagation, and exceptions;
+- shared feature configuration and integrations;
+- plans, quotas, billing, or licensing when administrator-visible;
+- audit, reporting, export, retention, deletion, and support evidence;
+- change verification, rollback, lockout recovery, and escalation.
+
+For each action, state the required role, affected scope, prerequisites,
+propagation or restart behavior, consequences, verification, and supported
+reversal. Put destructive or organization-wide effects before the final action.
+
+## Governance lens
+
+Explain how administrators can review effective configuration, detect drift or
+exceptions, transfer ownership, and prove a change took effect when those
+capabilities exist. Do not convert generic recommendations into product guarantees.
+
+## Standard navigation
+
+Promote `Administration` only when it is a substantial independent surface. Use:
+
+```text
+Administrator overview
+Initial setup
+Users and access
+Authentication
+Security and policy
+Product configuration
+Integrations
+Plans and usage
+Data management
+Administration operations
+Troubleshooting
+```
+
+Order setup, lockout prevention, and access control before lower-risk feature
+settings. Omit SSO, billing, audit, or retention destinations without evidence.
+
+## Senior quality gate
+
+An administrator can establish a safe baseline, delegate access, predict the
+scope of a change, verify effective state, avoid lockout, and recover from
+evidenced configuration failures without relying on hidden superuser knowledge.

package/skills/doxloop-authoring/references/type-api-reference.md

@@ -0,0 +1,66 @@
+# API-reference playbook
+
+Use for a supported public programmatic contract. Pair it with getting-started
+and task guidance when readers must learn or combine operations.
+
+## Declare the reference boundary
+
+Name the API, version or stability boundary, environment, and operations included.
+Exclude internal, experimental, generated-only, or unreachable interfaces unless
+the product explicitly supports them. Use the generator's native API-reference
+contract when available.
+
+## Cover every operation consistently
+
+Document, when supported:
+
+- method or operation name, path, purpose, and authorization;
+- content types, headers, path, query, cookie, and body parameters;
+- type, format, requiredness, default, allowed values, constraints, and semantics;
+- request examples using safe realistic data;
+- success status, headers, body schema, field meaning, and example;
+- error statuses, error body, cause, retryability, and reader action;
+- pagination, filtering, sorting, expansion, idempotency, and concurrency behavior;
+- permissions, limits, side effects, asynchronous state, and related events.
+
+Document reusable schemas once when that improves consistency, but keep operation-
+specific meaning next to the operation. Distinguish absent, null, empty, zero,
+and default values when the contract does.
+
+## Reconcile evidence
+
+Compare specifications, public route types, validation schemas, tests, and
+implementation. Report contradictions rather than silently choosing convenient
+values. A generated specification may establish shape but not operational
+guarantees; tests may demonstrate cases without defining the entire contract.
+
+## Standard navigation
+
+Promote `API reference` to top navigation only when it is a substantial primary
+surface. Use this left-navigation block:
+
+```text
+API overview
+  Base URLs and environments
+  Authentication
+  Request conventions
+  Response conventions
+  Versioning
+Resources
+  Resource groups and operations
+Data models
+Common behavior
+  Pagination, filtering, and sorting
+  Idempotency and concurrency
+  Limits
+Errors
+Events and webhooks
+```
+
+Group operations by reader-visible resources, not implementation controllers.
+
+## Senior quality gate
+
+Coverage is uniform across the declared public surface; required and optional
+values are unambiguous; examples conform to schemas; errors lead to a supported
+action; and no material contract fact must be inferred from a sample alone.

package/skills/doxloop-authoring/references/type-architecture-concepts.md

@@ -0,0 +1,61 @@
+# Architecture-and-concepts playbook
+
+Use when readers need a stable public mental model to make correct integration,
+administration, deployment, or operational decisions. Do not expose internals
+merely because source makes them visible.
+
+## Choose concepts with consequences
+
+Document a concept only when misunderstanding it changes reader action or
+outcome. Explain:
+
+- the problem or decision the concept addresses;
+- public components, actors, resources, and trust boundaries;
+- relationships, ownership, cardinality, scope, and lifecycle;
+- data or control flow and asynchronous boundaries;
+- invariants, constraints, failure domains, and observable states;
+- alternatives and tradeoffs supported by evidence;
+- tasks and reference where the reader applies the model.
+
+Use one term for each concept and align it with public interfaces. Prefer a
+small diagram plus equivalent prose when several components or state transitions
+interact. Label conceptual diagrams and avoid implying undocumented topology,
+scale, or security properties.
+
+## Reader relevance
+
+Adapt the boundary: developers need contract and lifecycle; administrators need
+scope and authority; operators need dependencies and failure domains; evaluators
+need capability and operating model. Keep internal implementation and repository
+structure out unless maintainers are the confirmed readers.
+
+## Standard navigation
+
+Keep concepts under Documentation unless Architecture is a major reader surface:
+
+```text
+System overview
+Core concepts
+  Primary resources
+  Relationships and ownership
+  Lifecycle
+Architecture
+  Public components
+  Data and control flow
+  Asynchronous boundaries
+Security model
+Behavior and consistency
+Deployment models
+Design decisions and tradeoffs
+Limitations
+Glossary
+```
+
+Order concepts by dependency. Never mirror source packages or internal service
+names unless maintainers are the confirmed readers.
+
+## Senior quality gate
+
+After reading, the intended reader can predict important observable behavior,
+choose between supported approaches, and understand the consequence of a
+boundary or lifecycle state without memorizing implementation details.

package/skills/doxloop-authoring/references/type-cli-manual.md

@@ -0,0 +1,61 @@
+# CLI-manual playbook
+
+Use when readers need both task-oriented command guidance and consistent lookup
+for a command hierarchy.
+
+## Architect the manual
+
+Provide installation and first success, then group tasks by reader outcome and
+reference by command hierarchy. Put global concepts—configuration, profiles,
+authentication, output formats, environment variables, and exit behavior—in
+shared pages when they apply across commands.
+
+## Command contract
+
+For every supported command, document:
+
+- syntax and purpose;
+- positional arguments and accepted forms;
+- local and inherited options, defaults, repeatability, and mutual exclusions;
+- config and environment precedence;
+- input sources and supported formats;
+- stdout, stderr, machine-readable output, and exit status;
+- prompts, TTY or non-interactive behavior, side effects, and confirmation;
+- complete examples and consequential limitations.
+
+Keep aliases and deprecated commands clearly labeled. Avoid repeating the same
+global option details under every command unless the generator cannot provide a
+usable shared reference.
+
+## Automation lens
+
+Show safe quoting, deterministic selection of context or profile, structured
+output processing, prompt suppression, secret handling, exit checking, and dry
+run where supported. Separate shell-specific examples or declare the shell.
+
+## Standard navigation
+
+Promote `Command reference` for a command-heavy product. Use this block:
+
+```text
+CLI overview
+Getting started
+Common workflows
+Configuration
+Command reference
+  Global options
+  Command groups
+Input and output
+Automation
+Troubleshooting
+Upgrade the CLI
+Release notes
+```
+
+Order commands by hierarchy inside reference and by reader outcome inside guides.
+
+## Senior quality gate
+
+The manual matches actual help and parser behavior, but adds the context help
+cannot provide: prerequisites, side effects, output meaning, failure handling,
+automation safety, and task-oriented sequences.

package/skills/doxloop-authoring/references/type-deployment-operations.md

@@ -0,0 +1,64 @@
+# Deployment-and-operations playbook
+
+Use when readers own installation, production configuration, deployment,
+observability, routine maintenance, upgrade, backup, or recovery.
+
+## Structure by operating lifecycle
+
+Organize evidence-backed content as:
+
+1. supported architecture and prerequisites;
+2. reference deployment or installation;
+3. production configuration and secrets;
+4. health verification and observability;
+5. scaling and routine operations;
+6. change, upgrade, and rollback;
+7. backup, restore, and disaster recovery;
+8. incident diagnostics and escalation.
+
+Do not publish a production checklist made of generic advice. Every requirement
+must connect to supported product behavior, a public dependency, or a clearly
+labeled organizational decision.
+
+## Procedure contract
+
+Every operational change includes scope, authority, dependencies, prechecks,
+backup or rollback prerequisites, explicit targets, ordered actions, expected
+signals, abort conditions, supported rollback, post-change verification, and
+cleanup. Distinguish control-plane success from workload health.
+
+## Configuration and signals
+
+Reference pages cover keys, types, defaults, precedence, reload behavior,
+sensitivity, and version support. Signal pages explain what health, logs,
+metrics, traces, and events mean and which reader action follows—without
+inventing thresholds.
+
+## Standard navigation
+
+Promote `Operations` only for operator-focused sites. Otherwise place this block
+inside Documentation:
+
+```text
+Operations overview
+Architecture and deployment models
+Plan the deployment
+Install and deploy
+Configuration reference
+Security and secrets
+Observability
+Routine operations
+Scaling and capacity
+Backup and recovery
+Upgrade and rollback
+Incident response
+Troubleshooting
+```
+
+Order prechecks and health verification before routine change or recovery.
+
+## Senior quality gate
+
+An operator can deploy the supported system, verify real readiness, manage
+configuration and secrets, perform routine change, observe failure, and execute
+supported rollback or recovery with a bounded blast radius.