@marinjursic/prc-linux-arm64 0.1.0

package/bin/docs/guides/ai-assisted-review.md

@@ -0,0 +1,61 @@
+# AI-assisted review
+
+AI agents can accelerate a production-readiness review, especially when controls can be evaluated from source, tests, infrastructure definitions, configuration schemas, and repository documentation. They should be used as evidence finders and gap detectors—not as autonomous release authorities.
+
+## What an agent can often inspect
+
+- build, test, lint, and deployment configuration;
+- dependency manifests, lockfiles, and update policy;
+- authentication, authorization, input handling, and security-sensitive code paths;
+- database migrations and backward-compatibility patterns;
+- automated tests and their relationship to critical journeys;
+- infrastructure-as-code, observability definitions, and runbooks;
+- documented architecture, recovery, incident, and support procedures;
+- the current diff and the controls it could invalidate.
+
+## What usually needs human or external evidence
+
+- the exact production configuration and deployed artifact;
+- successful backup restoration, failover, capacity, or incident drills;
+- alert delivery and on-call authority in real operating conditions;
+- legal, regulatory, privacy, accessibility, and contractual applicability;
+- third-party contracts, organizational processes, and staff availability;
+- penetration-test findings or production telemetry not present in the repository;
+- the authority to accept residual risk and approve a launch.
+
+An agent must label these controls **Blocked** or **Unknown**, not infer a pass from missing information.
+
+## Recommended workflow
+
+1. Put `CLAUDE.md` at the root of the application repository, or copy its instructions into the agent context.
+2. Choose [a full lifecycle review](../prompts/full-readiness-review.md), [a release-diff review](../prompts/release-diff-review.md), or [an evidence challenge](../prompts/evidence-challenge.md).
+3. Give the agent the release identifier, intended environment, architecture overview, critical journeys, and applicable conditional modules.
+4. Allow read-only inspection and relevant test commands. Require permission before code or configuration changes.
+5. Require a citation for each Pass: file and line, test output, command result, artifact, or external evidence reference.
+6. Have a qualified person review high-impact conclusions and every proposed exception.
+
+## Useful output contract
+
+Ask the agent to return:
+
+1. release and scope understood;
+2. immediate no-go findings;
+3. a control table with `USEQ-*` or `PRC-*` ID, status, evidence authority, limitations, owner, and next action;
+4. unknowns that require human or external evidence;
+5. changed controls invalidated by the release diff;
+6. prioritized blockers and recommended verification commands;
+7. an explicit statement that the agent is not making the final release decision.
+
+## Anti-patterns
+
+- Asking “is this production ready?” without release scope or evidence criteria.
+- Treating a repository-only release review as a complete lifecycle assessment when governance, product, operational, or external evidence was never supplied.
+- Treating the absence of a visible vulnerability as proof of security.
+- Allowing the agent to mark organizational or production-only controls as passed from source code.
+- Counting passed boxes or reporting a readiness percentage without blocker analysis.
+- Letting an agent accept risk on behalf of a named human owner.
+- Running destructive, load, failover, migration, or production tests without explicit authorization and safe boundaries.
+
+## Review the reviewer
+
+Challenge the agent’s findings. Check that cited evidence supports the exact control, pertains to the exact release, comes from the intended environment, is current enough, and demonstrates behavior rather than intent. The [evidence challenge prompt](../prompts/evidence-challenge.md) is designed for a second-pass review.

package/bin/docs/guides/getting-started.md

@@ -0,0 +1,78 @@
+# Getting started
+
+You can get useful release signal from this repository in 15 minutes, then deepen the review in proportion to the product and release risk.
+
+Choose the path before you begin:
+
+- For a new product, major redesign, baseline assessment, or organization-wide quality review, start with the [complete engineering review](../engineering/00-overview.md), complete phases 1–16, and then perform the production review.
+- For an imminent release with a trusted lifecycle baseline, use this quick start and revisit every lifecycle control affected by the change.
+
+## 1. Name the thing being approved
+
+Record the source commit, immutable artifact digest, configuration version, database migrations, feature-flag state, target environment, and release window. If those change, affected evidence must be reviewed again.
+
+Use the [release assessment template](../records/release-assessment.md) as the working record.
+
+## 2. Run the no-go screen
+
+Review all [immediate no-go conditions](../checklists/01-release-foundations.md#2-immediate-no-go-conditions). They are phrased as dangerous conditions: check one when the condition is true. Any checked no-go item stops the release until it is resolved or the release scope changes.
+
+Do this before the full assessment. It prevents a long checklist from obscuring a single decisive failure.
+
+## 3. Decide what applies
+
+The 16 engineering phases cover the product lifecycle, and the ten production tracks test the exact release. Specialized and conditional modules become mandatory whenever their trigger exists:
+
+- payments, billing, subscriptions, or money movement;
+- multi-tenant SaaS;
+- user-generated content, communities, or marketplaces;
+- email, SMS, push, or notifications;
+- localization and internationalization;
+- public content and SEO;
+- PWA or offline operation;
+- real-time, collaborative, or event-driven features;
+- high-risk administrative tools;
+- AI, machine learning, or LLM features;
+- safety-critical or physically consequential behavior.
+
+Record why an entire track or individual control is not applicable. Unexplained exclusions are gaps.
+
+## 4. Assign owners by track
+
+One coordinator should own the assessment, but evidence should come from the people accountable for each area: product, engineering, quality, security, reliability, data, privacy, accessibility, legal, support, and business risk.
+
+Avoid assigning a team name alone. Each unresolved item needs a person who can make or escalate the decision.
+
+## 5. Evaluate controls with evidence
+
+Use these statuses consistently:
+
+| Status | Meaning |
+| --- | --- |
+| Pass | Current evidence demonstrates the control for the exact release and environment |
+| Fail | Evidence demonstrates that the control is not met |
+| Blocked | Evidence is missing, inaccessible, stale, or cannot yet be collected |
+| Not Applicable | The trigger is absent and the written rationale has been reviewed |
+
+Use [evidence records](../records/evidence-record.md) for material controls. An implementation description is not proof that the deployed control works.
+
+## 6. Handle exceptions explicitly
+
+Do not relabel a failure as passed. Create a [risk exception](../records/risk-exception.md) with the business impact, accountable risk owner, compensating control, monitoring, remediation date, and automatic expiry.
+
+Some controls are release blockers and should not be waived through an ordinary exception process.
+
+## 7. Decide and retain
+
+Assemble the final evidence package, collect the required sign-offs, and use the [go/no-go record](../records/go-no-go-decision.md). Store the assessment beside the release record so that it remains traceable after the next deployment.
+
+## Suggested review depths
+
+| Release profile | Suggested approach |
+| --- | --- |
+| Low-risk internal change | No-go screen, changed tracks, smoke tests, rollback evidence, named approver |
+| Normal customer-facing release | Affected lifecycle phases, all applicable production tracks, conditional modules, independent review, complete evidence package |
+| New product, major redesign, or new baseline | All 16 lifecycle phases followed by all applicable production tracks |
+| High-impact or regulated launch | Full lifecycle and production assessment, specialist review, rehearsals, external testing where warranted, formal sign-off |
+
+Depth can vary; honesty about missing evidence cannot.

package/bin/docs/index.md

@@ -0,0 +1,66 @@
+---
+description: 10,042 evidence-driven controls for engineering and shipping secure, reliable, and supportable software.
+---
+
+# Production Readiness Checklist
+
+**Know what's ready and what still needs work.** Production Readiness Checklist is an open-source project scanner and review system for evaluating software from initial governance and requirements through design, implementation, operations, and final production approval. It provides **10,042 technology-neutral controls**, stable evidence IDs, reusable decision records, and guidance for automated, human, or AI-assisted reviews.
+
+The control set has two connected layers: **8,621 lifecycle and quality controls** across 16 engineering phases, followed by **1,421 production-readiness controls** for the release decision. It does not produce a readiness score. Every applicable requirement needs current evidence, and one material failure can block approval.
+
+## Start here
+
+| Your goal | Start with | What you will produce |
+| --- | --- | --- |
+| Evaluate a product from start to finish | [Complete engineering review](engineering/00-overview.md) | A disposition for every applicable lifecycle and release control |
+| Check an upcoming release quickly | [15-minute quick start](guides/getting-started.md) | A scoped assessment and an initial no-go decision |
+| Ask Claude or another agent to inspect a repository | [AI-assisted review](guides/ai-assisted-review.md) | Evidence-backed findings with explicit unknowns |
+| Understand where the added material came from | [Source consolidation manifest](engineering/source-manifest.md) | A document-by-document import and deduplication record |
+
+## Complete review sequence
+
+1. Define the product, lifecycle, organization, release, and evidence boundaries.
+2. Work through [engineering phases 1–16](engineering/00-overview.md), recording Pass, Fail, Blocked, or Not Applicable for every control.
+3. Apply all specialized modules whose trigger exists, including accessibility, privacy, AI, safety, marketplaces, and regulated domains.
+4. Run the [production no-go screen](checklists/01-release-foundations.md#2-immediate-no-go-conditions) and the ten release tracks.
+5. Collect current evidence, resolve or accept risk through the proper authority, obtain sign-offs, and verify the deployed system.
+
+The order gives reviewers a dependable path through the material; it does not require waterfall development. Teams can assess phases iteratively and revisit controls whenever a design, dependency, environment, or release changes.
+
+## Help expand the project
+
+This is an open-source, community-improvable control set. If you find a missing, duplicated, unclear, outdated, or incorrectly categorized control, you can [propose a checklist improvement](https://github.com/MarinJursic/production-readiness-checklist/issues/new?template=control-proposal.yml). Contributions to evidence guidance, documentation, navigation, validation, and tooling are also welcome; see the [contribution guide](https://github.com/MarinJursic/production-readiness-checklist/blob/main/CONTRIBUTING.md).
+
+## The scanner
+
+Production Readiness Checklist can inspect a repository and its available engineering evidence against the complete control set. It maps every result to a stable control ID, cites the evidence behind each conclusion, distinguishes verified facts from unknowns, and generates a prioritized report of failures, blocked checks, manual verification work, and next actions.
+
+The automated coverage is still growing. Production Readiness Checklist remains technology-neutral, treats unavailable production and organizational evidence as unknown rather than passed, and leaves risk acceptance and release approval to accountable humans.
+
+## Coverage map
+
+| Review layer | Categories | Purpose |
+| --- | --- | --- |
+| Foundations | Governance, product, requirements, UX, architecture | Establish intent, scope, ownership, risk, and system design |
+| Construction | Code, services, APIs, data, security, privacy, testing | Verify the product and its implementation properties |
+| Delivery and operation | Developer experience, platform, delivery, SRE, support, documentation | Verify that teams can build, deploy, observe, recover, and maintain it |
+| Specialized assurance | Trust and safety, ecosystems, AI/ML, specialized domains | Apply triggered controls without breaking the main review sequence |
+| Production decision | Ten production-readiness tracks | Approve the exact artifact, configuration, environment, and release |
+
+## Evidence states
+
+| State | Meaning |
+| --- | --- |
+| **Pass** | Current evidence demonstrates that the control is satisfied. |
+| **Fail** | Evidence demonstrates that the control is not satisfied. |
+| **Blocked** | Required access, evidence, or work is missing. |
+| **Not Applicable** | The trigger is absent and a reviewed reason is recorded. |
+
+> Every applicable requirement has current evidence; no known risk exceeds the organization's tolerance; critical user journeys meet defined reliability and security objectives; and the organization can detect, contain, roll back, restore, support, and communicate failures.
+
+## Templates and project links
+
+- Record the review with the [release assessment](records/release-assessment.md), [evidence record](records/evidence-record.md), [risk exception](records/risk-exception.md), and [go/no-go decision](records/go-no-go-decision.md) templates.
+- Review the [references, standards snapshot, and limitations](references.md).
+- [Contribute a control, correction, documentation improvement, or scanner capability](https://github.com/MarinJursic/production-readiness-checklist/blob/main/CONTRIBUTING.md).
+- [Star the repository on GitHub](https://github.com/MarinJursic/production-readiness-checklist) or share the documentation on [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fmarinjursic.github.io%2Fproduction-readiness-checklist%2F) or [X](https://twitter.com/intent/tweet?text=Production%20Readiness%20Checklist%3A%20know%20what%27s%20ready%20and%20what%20still%20needs%20work.&url=https%3A%2F%2Fmarinjursic.github.io%2Fproduction-readiness-checklist%2F).

package/bin/docs/prompts/evidence-challenge.md

@@ -0,0 +1,26 @@
+# Evidence challenge
+
+Use a second reviewer—or a fresh agent context—to challenge a completed assessment.
+
+```text
+Act as an independent reviewer of the attached production-readiness assessment. Follow CLAUDE.md, but do not repeat the original audit from scratch unless necessary.
+
+For every claimed Pass or Not Applicable result:
+- verify that the cited evidence exists;
+- verify that it supports the exact PRC control rather than a nearby or weaker claim;
+- verify that it covers the exact release, artifact, configuration, environment, migration state, and feature flags in scope;
+- verify that it demonstrates behavior rather than intent;
+- assess whether it is current enough;
+- identify self-review, circular evidence, or untested assumptions;
+- challenge Not Applicable rationales against product features, data, users, jurisdictions, dependencies, and risks.
+
+Also identify:
+- any immediate no-go condition hidden by wording, status, or exception;
+- failures relabeled as accepted risk without an authorized owner and expiry;
+- production or organizational controls incorrectly passed from repository evidence;
+- material controls omitted from the assessment;
+- changes made after evidence collection;
+- contradictions between test results, configuration, documentation, and the assessment.
+
+Return a table with Control ID, Original status, Challenged status, Reason, Evidence gap, and Required action. Do not calculate a score or make the final release decision.
+```

package/bin/docs/prompts/full-readiness-review.md

@@ -0,0 +1,34 @@
+# Full production-readiness review
+
+Copy the prompt below into Claude, Codex, or another coding agent with access to the application repository and this checklist.
+
+```text
+Perform a read-only, full-lifecycle engineering and production-readiness review of this repository.
+
+Follow CLAUDE.md. Use docs/engineering/00-overview.md as the master sequence: review engineering phases 1–16 in order, then use docs/checklists/ for the final production gate. Also run the immediate no-go screen early so a decisive release blocker is not hidden by the larger review.
+
+Release context:
+- Release identifier: [fill in]
+- Source commit or tag: [fill in]
+- Artifact digest: [fill in or unknown]
+- Target environment: [fill in]
+- Configuration and feature-flag state: [fill in or reference]
+- Critical user journeys: [fill in]
+- Expected traffic and risk profile: [fill in]
+- Conditional modules that apply: [fill in or ask the agent to assess]
+- Lifecycle phases already covered by accepted evidence: [fill in or none]
+
+Requirements:
+- Inspect source, tests, dependency files, CI/CD, infrastructure definitions, migrations, runbooks, and documentation.
+- Use both USEQ and PRC control IDs, and do not duplicate a finding when the same evidence satisfies related controls.
+- Run only safe, read-only or local verification commands.
+- Do not modify code or configuration.
+- Use Pass, Fail, Blocked, or Not Applicable exactly as defined in CLAUDE.md.
+- Cite precise evidence for every Pass.
+- Never infer production or organizational evidence from source code.
+- Put missing human or external evidence in a separate section.
+- Do not produce a readiness percentage.
+- Prioritize immediate no-go findings and controls that could cause security, privacy, data-integrity, financial, legal, safety, or unrecoverable operational harm.
+
+Return the output structure required by CLAUDE.md and end with the smallest practical set of next actions needed to reach a defensible go/no-go decision.
+```

package/bin/docs/prompts/release-diff-review.md

@@ -0,0 +1,31 @@
+# Release-diff readiness review
+
+Use this prompt when the application has a known-good baseline and you need to understand what a release changes or invalidates.
+
+```text
+Review the proposed release diff for engineering-quality and production-readiness impact. Follow CLAUDE.md, map affected lifecycle controls under docs/engineering/, and use docs/checklists/ for the final release gate.
+
+Baseline release: [commit/tag/artifact]
+Candidate release: [commit/tag/artifact]
+Target environment: [environment]
+Change summary: [summary or issue/PR links]
+Critical journeys touched: [list]
+
+Tasks:
+1. Inspect the complete diff, including dependencies, lockfiles, migrations, infrastructure, workflows, configuration schemas, feature flags, tests, documentation, and generated artifacts.
+2. Map each material change to affected USEQ and PRC control IDs.
+3. Identify immediate no-go conditions introduced or made uncertain by the change.
+4. Identify earlier evidence that is invalidated and must be collected again.
+5. Identify compatibility risks during mixed-version deployment, rollback, roll-forward, queued work, cached data, and database migration.
+6. Recommend the smallest sufficient regression, security, accessibility, performance, resilience, and post-deployment verification set.
+7. Use Pass, Fail, Blocked, or Not Applicable. Cite exact evidence and state assumptions.
+8. Do not modify files, run destructive commands, or make the final release decision.
+
+Return:
+- scope and assumptions;
+- blockers;
+- affected-control table with ID, impact, status, evidence, and required verification;
+- invalidated-evidence list;
+- recommended pre-deploy and post-deploy checks;
+- human or external decisions needed.
+```

package/bin/docs/records/evidence-record.md

@@ -0,0 +1,42 @@
+# Evidence record: [control ID]
+
+| Field | Value |
+| --- | --- |
+| Control ID and text | |
+| Status | Pass / Fail / Blocked / Not Applicable |
+| Accountable owner | |
+| Implementer | |
+| Independent reviewer | |
+| Release identifier | |
+| Source commit/tag | |
+| Artifact digest | |
+| Configuration and flags | |
+| Environment | |
+| Evidence collected at | |
+| Evidence expires at | |
+
+## Applicability
+
+Explain why this control applies. For Not Applicable, identify the absent trigger and how that was verified.
+
+## Evidence
+
+Link the test report, command output, screenshot, query, configuration export, code review, architecture decision, contract, drill report, or monitoring view. Do not paste secrets or unnecessary personal data.
+
+## Why the evidence is sufficient
+
+Explain how the evidence demonstrates the complete control for this release and environment, including important limitations.
+
+## Reproduction or verification
+
+```text
+[safe command, test procedure, or review steps]
+```
+
+## Result and follow-up
+
+- Result:
+- Residual risk:
+- Related defects or exceptions:
+- Conditions that invalidate this evidence:
+- Next review date:

package/bin/docs/records/go-no-go-decision.md

@@ -0,0 +1,63 @@
+# Go/no-go decision: [release identifier]
+
+## Decision context
+
+| Field | Value |
+| --- | --- |
+| Release/artifact/configuration | |
+| Target environment and scope | |
+| Evidence package | |
+| Meeting/time | |
+| Release authority | |
+| Participants | |
+
+## Gate summary
+
+| Gate | Result | Evidence or exception |
+| --- | --- | --- |
+| No immediate no-go condition is present | | |
+| Critical journeys meet approved objectives | | |
+| Current evidence covers every critical requirement | | |
+| No residual risk exceeds risk tolerance | | |
+| Rollout and stop criteria are ready | | |
+| Rollback or safe roll-forward is proven | | |
+| Restore and incident response are proven | | |
+| Monitoring, on-call, support, and communications are ready | | |
+| Required sign-offs are complete | | |
+
+## Open items
+
+| Control/exception | Impact | Owner | Due/expiry | Monitoring |
+| --- | --- | --- | --- | --- |
+| | | | | |
+
+## Decision
+
+Select one:
+
+- **GO** — Every release-blocking item passes and residual risk is within tolerance.
+- **CONDITIONAL GO** — Remaining issues are not blockers, have tested compensating controls, named risk owners, monitoring, remediation dates, and automatic expiry; launch scope is bounded.
+- **NO-GO** — Evidence is missing or stale, a blocker remains, recovery is unproven, required approval is absent, or remaining risk is not understood.
+
+Decision:
+
+Rationale:
+
+Conditions or reduced scope:
+
+Observation period:
+
+Stop, rollback, and incident-declaration thresholds:
+
+## Approval
+
+| Role | Name | Approve/Reject | Time | Notes |
+| --- | --- | --- | --- | --- |
+| Release authority | | | | |
+| Business risk owner | | | | |
+| Engineering/operations | | | | |
+| Required specialists | | | | |
+
+## Production-readiness declaration
+
+> Release [identifier], represented by artifact [digest] and configuration [version], has passed all applicable production-readiness gates documented in evidence package [reference]. No known unresolved risk exceeds the approved risk tolerance. Remaining accepted risks are recorded with owners, controls, monitoring, remediation dates, and expiry. Deployment, rollback or roll-forward, restoration, incident response, and customer communication have been tested and are ready.

package/bin/docs/records/release-assessment.md

@@ -0,0 +1,124 @@
+# Release readiness assessment: [release identifier]
+
+> Copy this file for each release. Link detailed evidence records instead of pasting secrets, personal data, or large raw reports.
+
+## Release identity
+
+| Field | Value |
+| --- | --- |
+| Release identifier | |
+| Source commit/tag | |
+| Artifact/image digest | |
+| Configuration version | |
+| Database migrations | |
+| Feature-flag state | |
+| Target environment/regions | |
+| Previous known-good release | |
+| Planned deployment window | |
+| Assessment owner | |
+| Evidence snapshot time | |
+
+## Scope
+
+### Critical user journeys
+
+- [Journey, user, expected outcome]
+
+### Included components
+
+- [Service, worker, frontend, scheduled job, infrastructure component]
+
+### Data and third parties
+
+- [Data classification, store, processor/provider]
+
+### Exclusions
+
+| Excluded area | Rationale | Reviewer |
+| --- | --- | --- |
+| | | |
+
+## Track applicability
+
+| Track | Required? | Owner | Rationale or evidence location |
+| --- | --- | --- | --- |
+| Release foundations | Yes | | |
+| Product, risk, and architecture | | | |
+| Source, build, and supply chain | | | |
+| Environments, quality, and experience | | | |
+| Application security | | | |
+| Data, privacy, and performance | | | |
+| Reliability and operations | | | |
+| Maintenance, vendors, and compliance | | | |
+| Conditional feature modules | | | |
+| Evidence, sign-off, and decision | Yes | | |
+
+## Immediate no-go screen
+
+No-go controls describe dangerous conditions. A **Yes** result stops the release.
+
+| Control | Condition present? | Evidence | Owner | Resolution |
+| --- | --- | --- | --- | --- |
+| PRC-02-001–PRC-02-020 | No / Yes / Unknown | | | |
+
+## Control results
+
+Duplicate rows as needed or link to a control-management system.
+
+| Control ID | Status | Evidence | Owner | Reviewer | Evidence date/expiry | Next action |
+| --- | --- | --- | --- | --- | --- | --- |
+| PRC- | Pass / Fail / Blocked / N/A | | | | | |
+
+## Open blockers and failures
+
+| Control ID | Impact | Owner | Required action | Due |
+| --- | --- | --- | --- | --- |
+| | | | | |
+
+## Risk exceptions
+
+| Exception | Controls | Risk owner | Compensating control | Expiry |
+| --- | --- | --- | --- | --- |
+| | | | | |
+
+## Evidence package
+
+- Architecture and data-flow diagrams:
+- Threat model:
+- Test reports:
+- Security and dependency reports:
+- Accessibility evidence:
+- Performance and capacity evidence:
+- Resilience, restore, and rollback evidence:
+- Monitoring, alerting, on-call, and runbooks:
+- Legal, privacy, contractual, and third-party review:
+- Deployment and post-deployment plan:
+
+## Sign-offs
+
+| Area | Signer | Decision | Date | Notes |
+| --- | --- | --- | --- | --- |
+| Product | | Approve / Reject / Conditional | | |
+| Engineering | | | | |
+| Quality | | | | |
+| Security | | | | |
+| Reliability/operations | | | | |
+| Data | | | | |
+| Privacy | | | | |
+| Accessibility | | | | |
+| Legal/compliance | | | | |
+| Support | | | | |
+| Business risk | | | | |
+| Release authority | | | | |
+
+## Decision
+
+- Decision: **GO / CONDITIONAL GO / NO-GO**
+- Decision-maker:
+- Time:
+- Rationale:
+- Observation period:
+- Stop/rollback criteria:
+- Follow-up review:
+
+Use the full [go/no-go decision record](go-no-go-decision.md) for material launches.

package/bin/docs/records/risk-exception.md

@@ -0,0 +1,64 @@
+# Risk exception: [short title]
+
+> An exception records accepted residual risk. It does not convert a failed control into a pass.
+
+For scanner-bound decisions, use the signed
+[`prc.risk-exception/v0.1`](../scanner/risk-exceptions.md) contract so the
+decision is tied to one immutable run and finding, independently reviewed,
+automatically expiring, and cryptographically attributable.
+
+| Field | Value |
+| --- | --- |
+| Exception ID | |
+| Affected release/environment | |
+| Affected control IDs | |
+| Requested by | |
+| Accountable risk owner | |
+| Security/privacy/legal reviewers | |
+| Created at | |
+| Automatic expiry | |
+| Remediation owner and due date | |
+
+## Failed or blocked requirement
+
+Describe the requirement, current condition, affected users/data/systems, and why it cannot be resolved before the release decision.
+
+## Risk analysis
+
+- Threat or failure scenario:
+- Likelihood and basis:
+- Impact and blast radius:
+- User, security, privacy, integrity, financial, legal, safety, and operational effects:
+- Detection limitations:
+- Worst credible outcome:
+
+## Compensating controls
+
+Describe controls already implemented and attach evidence that they work. Planned controls are remediation, not compensation.
+
+## Monitoring and response
+
+- Detection signal and threshold:
+- Dashboard/alert owner:
+- Immediate containment:
+- Feature disablement or rollback path:
+- Incident declaration criteria:
+
+## Scope reduction
+
+Record any cohort, region, feature, traffic, data, or permission reduction used to bound the risk.
+
+## Decision
+
+- Decision: Approve / Reject
+- Risk owner:
+- Decision date:
+- Rationale:
+- Required conditions:
+
+## Closure
+
+- Remediation evidence:
+- Closed by:
+- Closed at:
+- Review of any incidents or near misses:

package/bin/docs/references.md

@@ -0,0 +1,52 @@
+# References and scope
+
+The checklist is technology-neutral and synthesizes lifecycle governance, product quality, software engineering, secure development, accessibility, software supply chain, identity, incident response, operations, and reliability practices.
+
+## Structure rationale
+
+The 16-phase sequence follows the whole-lifecycle scope of ISO/IEC/IEEE 12207 and the breadth of the SWEBOK Guide while remaining usable as one navigable review. ISO/IEC 25010 provides a product-quality lens, and NIST SSDF keeps secure development outcome- and risk-oriented. WCAG, OWASP ASVS, NIST AI RMF, and other specialist sources inform triggered domains. The production tracks remain the final assessment of the exact artifact and operating environment.
+
+The sequence is not a prescribed development process. Teams may work iteratively or concurrently and revisit controls when assumptions, architecture, dependencies, data, or release state change.
+
+## Standards snapshot
+
+The integrated checklist was reviewed on **August 15, 2026**. Verify current versions and applicability before making the controls a formal engineering or release gate.
+
+- [ISO/IEC/IEEE 12207:2026 — software lifecycle processes](https://www.iso.org/standard/90219.html)
+- [IEEE Computer Society — SWEBOK Guide V4.0 knowledge areas](https://www.computer.org/education/bodies-of-knowledge/software-engineering/topics)
+- [ISO/IEC 25010:2023 — product quality model](https://www.iso.org/standard/78176.html)
+- [NIST SP 800-218 — Secure Software Development Framework 1.1](https://csrc.nist.gov/pubs/sp/800/218/final)
+- [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/)
+- [W3C Web Content Accessibility Guidelines 2.2](https://www.w3.org/TR/WCAG22/)
+- [SLSA specification 1.2](https://slsa.dev/spec/v1.2/)
+- [NIST SP 800-63 Revision 4 — Digital Identity Guidelines](https://pages.nist.gov/800-63-4/)
+- [NIST SP 800-61 Revision 3 — Incident Response Recommendations](https://csrc.nist.gov/pubs/sp/800/61/r3/final)
+- [FIRST CVSS v4.0 implementation guidance](https://www.first.org/cvss/v4.0/implementation-guide)
+- [CISA software bill of materials resources](https://www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom)
+- [Google SRE Workbook — implementing SLOs](https://sre.google/workbook/implementing-slos/)
+- [DORA — software delivery performance metrics](https://dora.dev/guides/dora-metrics/)
+- [web.dev — Core Web Vitals](https://web.dev/articles/vitals)
+- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
+- [OWASP Artificial Intelligence Security Verification Standard](https://owasp.org/www-project-artificial-intelligence-security-verification-standard-aisvs-docs/)
+
+## Frequently triggered legal and regulatory references
+
+- [EU General Data Protection Regulation](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng)
+- [PCI Security Standards Council document library](https://www.pcisecuritystandards.org/document_library/)
+- [US HHS HIPAA Security Rule resources](https://www.hhs.gov/hipaa/for-professionals/security/index.html)
+- [US FTC Children’s Online Privacy Protection Rule](https://www.ftc.gov/legal-library/browse/rules/childrens-online-privacy-protection-rule-coppa)
+- [European Accessibility Act](https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng)
+
+These links are starting points, not a complete applicability analysis.
+
+## Limitations
+
+- This project is not legal advice, certification, or a guarantee of security or reliability.
+- Controls must be tailored to the application’s users, data, architecture, markets, contracts, and risk.
+- A source-code review cannot substitute for production evidence, operating drills, qualified human review, or accountable risk acceptance.
+- Standards, laws, threat techniques, provider behavior, and dependencies change over time.
+- Some high-risk systems need controls beyond this checklist.
+
+Use the [source consolidation manifest](engineering/source-manifest.md) to trace the supplied archive documents, import counts, deduplication rules, and archive hashes.
+
+When requirements conflict, document the conflict, obtain qualified review, and record who approved the resolution.