jupytermind 0.3.0

package/.github/skills/tech-writer/references/doctypes/migration-plan.md

@@ -0,0 +1,63 @@
+# Migration plan type
+
+A migration plan defines how data, users, integrations, and business
+processes move from a current state to a target state with measurable
+validation, controlled downtime, and a tested rollback path.
+
+## Target reader
+
+Migration leads, application and data engineers, business owners, operators,
+support teams, security reviewers, and Go/No-Go approvers.
+
+## Settle before writing
+
+- The current and target states and complete migration inventory
+- Allowed downtime, data-loss tolerance, and business continuity needs
+- Migration approach, waves, dependencies, and change-freeze conditions
+- Reconciliation and business-acceptance criteria
+- Go/No-Go and rollback authority, triggers, and deadlines
+- Rehearsal evidence, communication needs, and post-migration support
+
+## Responsibility boundary
+
+Own the executable transition plan and its decisions. Link to implementation
+scripts rather than embedding large programs. Do not claim rollback is
+possible unless the plan states how post-cutover writes and data consistency
+will be handled.
+
+The migration section in `system-design` is sufficient for describing the
+chosen transition architecture. Use a standalone `migration-plan` when the
+cutover needs rehearsals, a timed procedure, business communications,
+Go/No-Go gates, reconciliation evidence, or separate approval. When both
+exist, the migration plan is authoritative for execution and the system
+design summarizes the strategy and links to it.
+
+## Template
+
+Start from `assets/templates/migration-plan.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Agreement target, current and target states, scope, and constraints
+2. Inventory, dependencies, mappings, transformation, and migration method
+3. Roles, rehearsals, readiness, and timed production procedure
+4. Reconciliation, Go/No-Go gates, rollback, and business continuity
+5. Security, communication, stabilization, decommissioning, and approval
+
+## Checklist
+
+- [ ] Are all data, configuration, identities, integrations, and business
+      processes inventoried with owners and dependencies?
+- [ ] Are mapping, transformation, default, rejection, retry, and idempotency
+      rules explicit?
+- [ ] Have full-scale timing, validation, and rollback been rehearsed?
+- [ ] Are start, cutover, reopen, Go/No-Go, and rollback conditions objective?
+- [ ] Do reconciliation checks cover counts, aggregates, referential
+      integrity, and business scenarios?
+- [ ] Does rollback address writes made after cutover and its last safe time?
+- [ ] Are downtime communications, alternative operations, support, security,
+      temporary access, and evidence covered?
+- [ ] Are stabilization, cleanup, old-system retention, and decommissioning
+      conditions defined?

package/.github/skills/tech-writer/references/doctypes/operations-runbook.md

@@ -0,0 +1,63 @@
+# Operations design and runbook type
+
+An operations design and runbook makes a production service observable,
+changeable, recoverable, and supportable. It combines stable operating
+policies with executable procedures for routine work and incidents.
+
+## Target reader
+
+Service owners, on-call engineers, operators, support staff, security teams,
+change approvers, and incident commanders.
+
+## Settle before writing
+
+- The service boundary, owners, dependencies, and operating hours
+- SLI, SLO, alert, capacity, backup, RTO, and RPO targets
+- On-call, escalation, change, and incident authority
+- Access requirements and safety constraints for operational actions
+- The symptoms and failure scenarios that require executable runbooks
+- Review, exercise, and expiration frequency
+
+## Responsibility boundary
+
+Write steps that an authorized operator can execute and verify. Link to
+automation where it exists, but preserve preconditions, safety checks,
+expected results, escalation, and recovery behavior. Never include secret
+values or bypass access and change controls.
+
+The operations section in `system-design` is sufficient for architectural
+operability decisions. Use a standalone `operations-runbook` when on-call
+staff need executable procedures, alerts, escalation, exercises, or a review
+cycle independent of the system design. When both exist, the runbook is
+authoritative for live operations and the system design links to its current
+approved version.
+
+## Template
+
+Start from `assets/templates/operations-runbook.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Service scope, dependencies, levels, owners, and escalation
+2. Observability, alerts, routine work, and capacity management
+3. Incident severity, common initial response, and symptom runbooks
+4. Start, stop, restore, security, change, and rollback procedures
+5. Disaster recovery, business continuity, risks, exercises, and review
+
+## Checklist
+
+- [ ] Can an unfamiliar authorized operator identify the service, owner,
+      dependencies, dashboards, communication channels, and impact?
+- [ ] Are SLI/SLO calculations, alert conditions, suppression, and test
+      frequency specified?
+- [ ] Does every procedure state preconditions, safety limits, steps,
+      expected results, evidence, escalation, and recovery?
+- [ ] Are backup restoration, RTO/RPO, disaster recovery, and exercises
+      executable and owned?
+- [ ] Are access, secret, certificate, vulnerability, audit, and security
+      incident operations covered without exposing secret values?
+- [ ] Are releases, emergency changes, rollback, and post-change checks clear?
+- [ ] Are capacity, cost, routine maintenance, review dates, and stale
+      runbook detection addressed?

package/.github/skills/tech-writer/references/doctypes/pr-commit.md

@@ -0,0 +1,82 @@
+# PR description / commit message / issue report type
+
+This doctype directly affects a reviewer's decision speed, so apply it more
+strictly than the other types.
+
+## Commit messages
+
+### Format
+
+```text
+<type>: <summary (imperative mood, ~50 chars)>
+
+<body (optional) - what and why the change was made; the diff already
+shows the "what" implementation details, so don't repeat them>
+
+<footer (optional) - Fixes #123, BREAKING CHANGE: ... etc.>
+```
+
+- Use imperative mood consistently in the summary line (e.g. "Fix", not
+  "Fixed"/"Fixes").
+- The body should explain *why* the change was made, not restate *what*
+  changed — the diff already shows that.
+- One concern per commit. Don't bundle unrelated changes into one commit
+  message.
+
+### Checklist
+
+- [ ] Can the change be inferred from the summary line alone (not just
+      "fix" or "update")?
+- [ ] Does the body explain "why" rather than paraphrase the diff?
+- [ ] Is the related issue number in the footer?
+
+## PR descriptions
+
+### Recommended skeleton
+
+1. **What**: what changed, in 1–3 sentences.
+2. **Why**: why this change is needed (link to the background issue, bug
+   report, or request).
+3. **How**: the main approach. Leave implementation detail to code
+   comments and the diff; state only the design decisions here.
+4. **How to verify**: concrete steps the reviewer can use to reproduce and
+   verify — test commands, or where to find screenshots/GIFs.
+5. **Impact / breaking changes**: state explicitly if this affects other
+   teams' code or API consumers.
+6. **Remaining work / follow-ups** (if applicable): preempt likely review
+   questions about unfinished items.
+
+### Checklist
+
+- [ ] Are What/Why/How separated, so reading only "What" gives the shape
+      of the change?
+- [ ] Are there concrete steps (commands, URLs, repro conditions) the
+      reviewer can use to verify locally?
+- [ ] Are breaking changes, DB migrations, config changes — anything a
+      reviewer could miss and cause an incident — near the top?
+- [ ] Is there a link to the related issue/ticket?
+- [ ] For UI changes, are screenshots actually attached?
+
+## Issue reports (bug reports / feature requests)
+
+### Bug report skeleton
+
+1. **Summary**: the symptom, in one sentence.
+2. **Steps to reproduce**: numbered, with environment info (version, OS,
+   browser, etc.) stated *before* the steps.
+3. **Expected vs. actual result**: contrast them explicitly.
+4. **Impact**: who is affected, and how often.
+
+### Feature request skeleton
+
+1. **Problem to solve**: state the situation causing pain before the
+   feature itself.
+2. **Proposed solution** (optional): if you have one in mind.
+3. **Alternatives considered** (optional).
+
+### Checklist (issues, common)
+
+- [ ] Are the repro steps (or use case) concrete enough to reproduce
+      independent of the reader's environment?
+- [ ] Are "expected" and "actual" explicitly contrasted (bug reports)?
+- [ ] Is environment info stated before the repro steps?

package/.github/skills/tech-writer/references/doctypes/qiita.md

@@ -0,0 +1,75 @@
+# Qiita article type
+
+The article title lives in YAML frontmatter. Qiita's readership skews toward
+searching for a specific error message or task, so apply rule 3 (order
+matching how the reader looks for information) especially strictly here.
+
+## Target reader
+
+A developer who arrived via search for a specific error, API, or task, and
+is scanning to confirm this article addresses their exact situation.
+
+## Format
+
+Markdown, with Qiita's frontmatter and a few platform-specific extensions
+on top of GFM. The frontmatter `title` is the article title; body sections
+start at `#`, with `##` used for subsections.
+
+## Recommended frontmatter
+
+```yaml
+---
+title: <Article title>
+tags:
+  - <tag1>
+  - <tag2>
+private: false # true: limited-share draft, false: public
+organization_url_name: null # only if publishing under an Organization
+---
+```
+
+- `title` and `tags` are required; `private` defaults the article to
+  public once posted, so confirm it deliberately rather than leaving the
+  default unconsidered.
+- Qiita CLI also manages `updated_at`/`id`/`slide`/`ignorePublish` fields
+  automatically on publish/update — don't hand-edit those unless you know
+  why.
+
+## Template
+
+Start from `assets/templates/qiita.md`.
+Use `#` for the highest-level body sections and `##` for their subsections.
+
+## Recommended skeleton
+
+1. **Lead paragraph (right after frontmatter, before any heading)**: the
+   specific problem/error/task this article addresses and what the reader
+   will be able to do — this is rule 1's "first three lines" analog, since
+   there's no in-body title to carry it.
+2. **Environment / versions**: state the exact versions (language,
+   framework, OS) the article was verified against, before any steps —
+   Qiita readers frequently hit version-specific breakage.
+3. **Body sections, one concern per `#` heading**: order by how a reader
+   arriving via search would scan (rule 3) — put the fix/answer before
+   background explanation if the article is troubleshooting-oriented. Use
+   `##` only for subsections within one concern.
+4. **Code blocks with both a language tag and, where relevant, a filename**:
+   Qiita supports ` ```js:example.js ` — prefer this over a bare language
+   tag when the file identity matters to the reader.
+5. **References / further reading** (if applicable): official docs or
+   related articles, not a restatement of the body.
+
+## Checklist
+
+- [ ] Are `title` and `tags` present, and is `private` a deliberate choice
+      rather than an unconsidered default?
+- [ ] Does the lead paragraph right after frontmatter state the specific
+      problem/task addressed, since there's no in-body title to do that?
+- [ ] Do highest-level body sections use `#`, with `##` reserved for
+      subsections?
+- [ ] Are the exact versions/environment stated before the steps?
+- [ ] For troubleshooting-oriented articles, does the fix appear before
+      background explanation, matching how a reader arriving via search
+      would scan?
+- [ ] Do code blocks carry a language tag (and a filename where the file
+      identity matters)?

package/.github/skills/tech-writer/references/doctypes/readme.md

@@ -0,0 +1,43 @@
+# README type
+
+The recommended skeleton and checklist for a project README: the document
+most readers see first, and the one that decides whether they keep reading.
+
+## Target reader
+
+Someone visiting this repository for the first time. They want to judge
+"what is this", "do I need it", and "how do I start" within seconds.
+
+## Recommended skeleton
+
+1. **Title + one-sentence description**: right after the project name, say
+   what it does in one sentence.
+2. **What problem it solves (Why)**: problem → approach in 2–4 sentences,
+   before the feature list.
+3. **Key features / what you can do**: a bullet list, one feature per item,
+   starting with a verb.
+4. **Install / setup**: a command sequence that runs as copy-pasted.
+   Prerequisites (versions, OS, permissions) go in a separate section
+   *before* the steps.
+5. **Quickstart, headed with what it does**: the smallest successful
+   experience (a "hello world" equivalent) first, under a heading that
+   previews the concrete task (e.g. "Send your first request"), not the
+   generic label "Usage" (structure constitution rule 2). Move advanced
+   usage to a separate, similarly specific heading.
+6. **Configuration / options** (if applicable): a table (key, default,
+   description).
+7. **Known limitations / what's not supported**: don't omit this.
+8. **Contributing / license**: fine to leave at the end.
+
+## Checklist
+
+- [ ] Does the one-sentence description right after the title convey "what
+      this does"?
+- [ ] Do the install steps run top-to-bottom via copy-paste (no
+      prerequisite hidden mid-steps)?
+- [ ] Is the quickstart section headed with a specific, task-previewing
+      label instead of the generic "Usage", and does it show the smallest
+      successful experience rather than an exhaustive feature list?
+- [ ] Do badges/acknowledgments/license come after the main content, not
+      before it?
+- [ ] Does a known-limitations section exist?

package/.github/skills/tech-writer/references/doctypes/release-notes.md

@@ -0,0 +1,30 @@
+# Release notes / CHANGELOG type
+
+The recommended skeleton and checklist for a per-version changelog entry,
+written for a reader deciding whether and how to upgrade.
+
+## Target reader
+
+An existing user deciding whether to upgrade. Reading time: seconds to a
+few tens of seconds.
+
+## Recommended skeleton
+
+1. **Version + date**: always include both in the heading.
+2. **Breaking changes (topmost, if any)**: what breaks, with a link to the
+   migration steps. This is the one section that must never be omitted or
+   deferred.
+3. **Added / Changed / Fixed / Deprecated / Removed**: categorize per
+   [Keep a Changelog](https://keepachangelog.com/). One change per item,
+   starting with a verb.
+4. **Notes on affected user segments** (if applicable): scope it, e.g.
+   "affects only users of X".
+
+## Checklist
+
+- [ ] Are breaking changes at the top, with a migration path (or link)?
+- [ ] Does each item state "what changed and how" in one sentence (not a
+      raw copy of the commit message)?
+- [ ] Do the categories (Added/Changed/Fixed, etc.) match the actual
+      change?
+- [ ] Are both the version number and the date stated?

package/.github/skills/tech-writer/references/doctypes/requirements-definition.md

@@ -0,0 +1,61 @@
+# Requirements definition type
+
+A requirements definition establishes agreement on what outcomes, scope,
+capabilities, quality levels, and acceptance conditions a system must
+satisfy. It describes the required behavior and measurable constraints
+without prematurely prescribing the implementation architecture.
+
+## Target reader
+
+Business owners, product owners, users, architects, delivery teams,
+operators, security reviewers, and approvers who must agree on what will be
+built and how acceptance will be judged.
+
+## Settle before writing
+
+- The business problem, target users, and measurable outcome
+- In-scope and out-of-scope business processes, systems, and data
+- Requirement priorities and the authority that resolves conflicts
+- Constraints covering budget, schedule, law, policy, and existing systems
+- Measurable acceptance conditions for functional and non-functional needs
+- The identifier or naming convention used for traceability
+
+## Responsibility boundary
+
+State what the system must achieve and the constraints it must meet. Do not
+turn preferred products, component layouts, database schemas, or deployment
+topologies into requirements unless they are genuine externally imposed
+constraints. Put implementation choices in a system design document and
+link them back to requirement IDs.
+
+## Template
+
+Start from `assets/templates/requirements-definition.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Agreement target, background, problem, purpose, and success measures
+2. Scope, stakeholders, assumptions, and constraints
+3. Business flow, business rules, and prioritized functional requirements
+4. Measurable non-functional, data, and external-interface requirements
+5. Migration, operation, acceptance, and traceability
+6. Risks, open questions, approval, and change history
+
+## Checklist
+
+- [ ] Are purpose, scope, exclusions, stakeholders, assumptions, and
+      constraints explicit?
+- [ ] Does every requirement have a stable ID, priority, and independently
+      verifiable acceptance condition?
+- [ ] Are non-functional requirements measurable under stated conditions?
+- [ ] Are data ownership, classification, retention, quality, and deletion
+      requirements covered?
+- [ ] Are external interfaces, migration, operations, and failure handling
+      included where applicable?
+- [ ] Can each requirement be traced to a problem or objective and forward
+      to an acceptance test and design or implementation artifact?
+- [ ] Are implementation preferences separated from actual constraints?
+- [ ] Are unresolved items owned and time-bound, with approval and change
+      history recorded?

package/.github/skills/tech-writer/references/doctypes/rfi.md

@@ -0,0 +1,43 @@
+# Request for information (RFI) type
+
+An RFI gathers market, vendor, product, feasibility, and indicative pricing
+information before requirements or procurement strategy are final. It must
+not read like an award decision or demand proposal-level effort.
+
+## Target reader
+
+Potential suppliers preparing an overview-level response, and the internal
+team using those responses to refine requirements and decide whether to
+proceed to an RFP.
+
+## Settle before writing
+
+- The unknowns the market research must resolve
+- The respondent population and distribution/confidentiality level
+- The current-environment details safe to disclose before an NDA
+- The response schedule and single source of truth for dates
+- The intended next step, while avoiding any promise to issue an RFP
+
+## Template
+
+Start from `assets/templates/rfi.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Purpose, non-procurement disclaimer, and current context
+2. Overview-level company, product, architecture, and security questions
+3. Indicative implementation, support, roadmap, and pricing information
+4. Response format, authoritative schedule, and handling conditions
+5. Respondent checklist
+
+## Checklist
+
+- [ ] Does the document state that responses are not scored or ranked?
+- [ ] Does it request overview-level information rather than detailed design?
+- [ ] Are indicative prices clearly non-binding?
+- [ ] Are roadmap, constraints, and unsupported capabilities reportable?
+- [ ] Is sensitive configuration moved to an NDA-controlled annex?
+- [ ] Is the schedule the single source of truth for dates?
+- [ ] Does the disclaimer avoid promising procurement or an RFP?

package/.github/skills/tech-writer/references/doctypes/rfp.md

@@ -0,0 +1,46 @@
+# Request for proposal (RFP) type
+
+An RFP asks qualified suppliers for comparable, evaluable, and
+contract-ready proposals against explicit requirements, acceptance criteria,
+commercial terms, and a disclosed evaluation method.
+
+## Target reader
+
+Suppliers deciding whether and how to bid, evaluators scoring proposals, and
+procurement or legal reviewers preparing the resulting contract.
+
+## Settle before writing
+
+- Procurement scope, exclusions, budget model, and contract term
+- Must/Should/Could requirements and the consequence of failing a Must
+- Measurable acceptance criteria and payment milestones
+- Bidder eligibility, security, compliance, and subcontracting conditions
+- TCO period, price-scoring formula, category weights, and pass thresholds
+- The authoritative procurement schedule and confidentiality controls
+
+## Template
+
+Start from `assets/templates/rfp.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Procurement purpose, scope, exclusions, and current environment
+2. Functional, non-functional, security, migration, and support requirements
+3. Bidder eligibility, deliverables, acceptance, and payment
+4. Requested proposal contents, implementation schedule, and TCO pricing
+5. Evaluation formula, submission process, authoritative schedule, and terms
+6. Bidder submission checklist
+
+## Checklist
+
+- [ ] Can every functional and non-functional requirement be answered in a
+      structured, comparable format?
+- [ ] Are Must failures and bidder disqualification rules explicit?
+- [ ] Are deliverables linked to acceptance and payment conditions?
+- [ ] Are bidder eligibility and conflict/subcontractor disclosures covered?
+- [ ] Can all price rows be normalized into the stated TCO period?
+- [ ] Is the scoring formula reproducible by independent evaluators?
+- [ ] Is sensitive environment detail isolated in an NDA-controlled annex?
+- [ ] Is the schedule the single source of truth for all procurement dates?

package/.github/skills/tech-writer/references/doctypes/security-design.md

@@ -0,0 +1,71 @@
+# Security design and threat model type
+
+A security design and threat model identifies protected assets, trust
+boundaries, threats, controls, verification, and residual risk. It turns
+security and compliance requirements into reviewable implementation and
+operational decisions.
+
+## Target reader
+
+Architects, developers, platform and security engineers, privacy and
+compliance reviewers, operators, and accountable risk acceptors.
+
+## Settle before writing
+
+- System scope, architecture, data flows, trust boundaries, and environments
+- Assets, owners, sensitivity, retention, and regulatory obligations
+- Identities, roles, administrative paths, and external dependencies
+- Threat-model method and risk-rating approach
+- Security testing, exception, and residual-risk acceptance authority
+- The approved requirements and system-design baselines
+
+## Responsibility boundary
+
+Document security decisions and trace threats to controls and tests. Do not
+include credentials, private keys, exploitable production details, or
+instructions that bypass controls. Vulnerability findings needing restricted
+handling belong in the repository's approved security-reporting channel.
+
+The security section in `system-design` is sufficient for an integrated
+architecture summary. Use a standalone `security-design` when threat
+modeling, control ownership, compliance evidence, exceptions, or risk
+acceptance needs independent review. When both exist, the security design is
+authoritative for threats, controls, and residual risk.
+
+This document owns security-test intent by tracing requirements and threats
+to controls and planned tests, including the expected environment class and
+required evidence type. The `test-plan` owns actual execution environments,
+schedule, release gates, results, and evidence storage; copy the security
+test IDs, threat IDs, and control IDs into its traceability table.
+
+## Template
+
+Start from `assets/templates/security-design.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Scope, requirements, assets, data classification, and architecture
+2. Trust boundaries, identity, authentication, authorization, and threats
+3. Preventive, detective, and responsive controls with ownership
+4. Data, secret, API, audit, vulnerability, and supply-chain protection
+5. Security testing, incident response, residual risk, traceability, and approval
+
+## Checklist
+
+- [ ] Are system scope, assets, owners, data flows, and trust boundaries clear?
+- [ ] Are identities, authentication, authorization, privilege, session, and
+      recovery paths covered?
+- [ ] Does each credible threat identify affected assets, impact, likelihood,
+      controls, owner, and test?
+- [ ] Are encryption, key and secret lifecycle, retention, deletion, masking,
+      logging, and audit addressed?
+- [ ] Are input, output, API abuse, availability, dependency, build, artifact,
+      and supply-chain risks covered?
+- [ ] Are security tests, incident response, evidence preservation, and
+      notification responsibilities defined?
+- [ ] Is every exception time-bound, owned, compensated, and accepted by an
+      accountable risk owner?
+- [ ] Can requirements, assets, threats, controls, tests, and implementation
+      locations be traced end to end?

package/.github/skills/tech-writer/references/doctypes/system-design.md

@@ -0,0 +1,74 @@
+# System design type
+
+A system design explains how approved requirements will be realized through
+architecture, components, data, interfaces, deployment, security, quality
+controls, and operations. It must be detailed enough for implementation,
+testing, operation, and review without duplicating source code.
+
+## Target reader
+
+Architects, developers, testers, operators, security reviewers, and technical
+approvers who must verify that the design satisfies the requirements and can
+be built and operated safely.
+
+## Settle before writing
+
+- The approved requirements baseline and stable requirement IDs
+- The system boundary, design scope, environments, and external dependencies
+- The most important quality attributes and their measurable targets
+- Constraints on technology, deployment, security, compliance, cost, and time
+- The level of design detail needed for implementation and review
+- The owner of unresolved design decisions
+
+## Responsibility boundary
+
+Describe implementation choices and trace them to requirements. Do not
+silently redefine scope or acceptance criteria from the requirements
+definition. If the design exposes a missing, conflicting, or infeasible
+requirement, record it as an open issue and update the approved requirements
+through change control.
+
+Use `design-doc` or an ADR for one isolated decision and its alternatives.
+Use `system-design` when the reader needs the integrated design across
+components, data, interfaces, deployment, quality attributes, and operations.
+Its test, operation, migration, and security sections summarize the design
+decisions needed to understand the whole system. Split out a `test-plan`,
+`operations-runbook`, `migration-plan`, or `security-design` when that topic
+needs executable procedures, independent evidence, a different approval
+authority, or a separate lifecycle. When a standalone document exists, it is
+the source of truth for that topic; the system design links to and summarizes
+it instead of duplicating details.
+
+## Template
+
+Start from `assets/templates/system-design.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Agreement target, scope, assumptions, constraints, and design drivers
+2. Context, container, component, and processing-flow design
+3. Data, transaction, interface, and error-contract design
+4. Security, performance, capacity, availability, and reliability design
+5. Deployment, network, observability, operation, backup, and recovery
+6. Migration, release, rollback, test traceability, trade-offs, and approval
+
+## Checklist
+
+- [ ] Is the design boundary clear, and is the approved requirements
+      baseline identified?
+- [ ] Are major components assigned cohesive responsibilities with explicit
+      dependencies and interfaces?
+- [ ] Are data ownership, schemas, integrity, transactions, retention, and
+      deletion addressed?
+- [ ] Are authentication, authorization, encryption, audit, secrets, and
+      threat controls concrete and testable?
+- [ ] Are performance, capacity, availability, timeout, retry, idempotency,
+      backup, RTO, and RPO decisions quantified?
+- [ ] Are deployment, network boundaries, configuration, observability,
+      release, operation, and incident handling implementable?
+- [ ] Are migration, compatibility, rollback, and failure recovery covered?
+- [ ] Is every major design element traced to requirements and tests?
+- [ ] Are rejected alternatives, accepted trade-offs, risks, open decisions,
+      reviewers, and change history recorded?