@marinjursic/prc-linux-arm64 0.1.0

package/bin/docs/assets/hero.svg

@@ -0,0 +1,37 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1200 280" role="img" aria-labelledby="title desc">
+  <title id="title">Production Readiness Checklist</title>
+  <desc id="desc">A checklist shield beside the words Production Readiness Checklist: know what is ready and what still needs work.</desc>
+  <defs>
+    <linearGradient id="bg" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#111827"/>
+      <stop offset="0.55" stop-color="#312e81"/>
+      <stop offset="1" stop-color="#115e59"/>
+    </linearGradient>
+    <linearGradient id="mark" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#818cf8"/>
+      <stop offset="1" stop-color="#2dd4bf"/>
+    </linearGradient>
+    <filter id="shadow" x="-30%" y="-30%" width="160%" height="160%">
+      <feDropShadow dx="0" dy="10" stdDeviation="12" flood-opacity=".25"/>
+    </filter>
+  </defs>
+  <rect width="1200" height="280" rx="24" fill="url(#bg)"/>
+  <circle cx="1120" cy="25" r="150" fill="#fff" opacity=".035"/>
+  <circle cx="1060" cy="270" r="110" fill="#2dd4bf" opacity=".07"/>
+  <circle cx="90" cy="250" r="125" fill="#818cf8" opacity=".06"/>
+  <g transform="translate(92 58)" filter="url(#shadow)">
+    <path d="M82 0 154 26v51c0 44-27 75-72 91C37 152 10 121 10 77V26L82 0Z" fill="url(#mark)"/>
+    <path d="m46 82 24 24 50-56" fill="none" stroke="#fff" stroke-width="14" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+  <text x="300" y="82" fill="#99f6e4" font-family="Inter, ui-sans-serif, system-ui, sans-serif" font-size="16" font-weight="750" letter-spacing="2.5">OPEN-SOURCE CHECKLIST &amp; PROJECT SCANNER</text>
+  <text x="298" y="137" fill="#fff" font-family="Inter, ui-sans-serif, system-ui, sans-serif" font-size="46" font-weight="750" letter-spacing="-1.5">Production Readiness Checklist</text>
+  <text x="302" y="178" fill="#ccfbf1" font-family="Inter, ui-sans-serif, system-ui, sans-serif" font-size="23" font-weight="500">Know what's ready and what still needs work.</text>
+  <g transform="translate(302 194)" font-family="Inter, ui-sans-serif, system-ui, sans-serif" font-size="16" font-weight="600">
+    <rect width="150" height="36" rx="18" fill="#fff" opacity=".12"/>
+    <text x="20" y="24" fill="#e0e7ff">10,042 controls</text>
+    <rect x="165" width="178" height="36" rx="18" fill="#fff" opacity=".12"/>
+    <text x="185" y="24" fill="#ccfbf1">read-only scanning</text>
+    <rect x="358" width="172" height="36" rx="18" fill="#fff" opacity=".12"/>
+    <text x="378" y="24" fill="#e0e7ff">Codex + Claude</text>
+  </g>
+</svg>

package/bin/docs/assets/logo.svg

@@ -0,0 +1,13 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" role="img" aria-labelledby="title">
+  <title id="title">Production Readiness Checklist</title>
+  <defs>
+    <linearGradient id="g" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#4f46e5"/>
+      <stop offset="1" stop-color="#0f766e"/>
+    </linearGradient>
+  </defs>
+  <rect width="64" height="64" rx="16" fill="url(#g)"/>
+  <path d="M17 18.5h30a3 3 0 0 1 3 3v27a3 3 0 0 1-3 3H17a3 3 0 0 1-3-3v-27a3 3 0 0 1 3-3Z" fill="none" stroke="#fff" stroke-width="4"/>
+  <path d="m21 29 4 4 7-8M21 43l4 4 7-8M36 29h8M36 43h8" fill="none" stroke="#fff" stroke-width="4" stroke-linecap="round" stroke-linejoin="round"/>
+  <path d="M24 14h16v9H24z" fill="#fff" rx="3"/>
+</svg>

package/bin/docs/assets/social-card.svg

@@ -0,0 +1,40 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1280 640" role="img" aria-labelledby="title desc">
+  <title id="title">Production Readiness Checklist</title>
+  <desc id="desc">Production Readiness Checklist: know what is ready and what still needs work. 10,042 controls plus a read-only project scanner.</desc>
+  <defs>
+    <linearGradient id="bg" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#0f172a"/>
+      <stop offset="0.55" stop-color="#312e81"/>
+      <stop offset="1" stop-color="#115e59"/>
+    </linearGradient>
+    <linearGradient id="mark" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#818cf8"/>
+      <stop offset="1" stop-color="#2dd4bf"/>
+    </linearGradient>
+    <filter id="shadow" x="-40%" y="-40%" width="180%" height="180%">
+      <feDropShadow dx="0" dy="18" stdDeviation="20" flood-opacity=".28"/>
+    </filter>
+  </defs>
+  <rect width="1280" height="640" fill="url(#bg)"/>
+  <circle cx="1180" cy="50" r="240" fill="#fff" opacity=".03"/>
+  <circle cx="1090" cy="620" r="210" fill="#2dd4bf" opacity=".07"/>
+  <circle cx="70" cy="590" r="220" fill="#818cf8" opacity=".06"/>
+  <path d="M0 515C240 445 405 565 640 515s400-75 640-5v130H0Z" fill="#020617" opacity=".13"/>
+  <g transform="translate(92 108)" filter="url(#shadow)">
+    <path d="M142 0 268 45v90c0 78-47 131-126 159C63 266 16 213 16 135V45L142 0Z" fill="url(#mark)"/>
+    <path d="m78 144 42 42 88-98" fill="none" stroke="#fff" stroke-width="24" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+  <text x="425" y="171" fill="#99f6e4" font-family="Inter, ui-sans-serif, system-ui, sans-serif" font-size="20" font-weight="750" letter-spacing="3.4">OPEN-SOURCE CHECKLIST &amp; PROJECT SCANNER</text>
+  <text x="421" y="249" fill="#fff" font-family="Inter, ui-sans-serif, system-ui, sans-serif" font-size="57" font-weight="800" letter-spacing="-1.8">Production Readiness</text>
+  <text x="421" y="318" fill="#fff" font-family="Inter, ui-sans-serif, system-ui, sans-serif" font-size="57" font-weight="800" letter-spacing="-1.8">Checklist</text>
+  <text x="425" y="377" fill="#ccfbf1" font-family="Inter, ui-sans-serif, system-ui, sans-serif" font-size="28" font-weight="500">Know what's ready and what still needs work.</text>
+  <g transform="translate(425 425)" font-family="Inter, ui-sans-serif, system-ui, sans-serif" font-size="19" font-weight="700">
+    <rect width="180" height="48" rx="24" fill="#fff" opacity=".12"/>
+    <text x="25" y="31" fill="#e0e7ff">10,042 controls</text>
+    <rect x="196" width="220" height="48" rx="24" fill="#fff" opacity=".12"/>
+    <text x="221" y="31" fill="#ccfbf1">read-only scanning</text>
+    <rect x="432" width="196" height="48" rx="24" fill="#fff" opacity=".12"/>
+    <text x="457" y="31" fill="#e0e7ff">Codex + Claude</text>
+  </g>
+  <text x="425" y="545" fill="#a5b4fc" font-family="ui-monospace, SFMono-Regular, Consolas, monospace" font-size="19">github.com/MarinJursic/production-readiness-checklist</text>
+</svg>

package/bin/docs/checklists/00-readiness-principle.md

@@ -0,0 +1,17 @@
+# The readiness principle
+
+> Production readiness is an evidence-backed risk decision, not a promise of perfection.
+
+## First: what “production-ready without any issues” can honestly mean
+
+No finite checklist, automated test suite, penetration test, or review can prove that a nontrivial web application contains **zero defects** or will experience **zero incidents**. Dependencies change, traffic behaves unexpectedly, external services fail, threat techniques evolve, and some defects are reachable only under conditions that testing did not reproduce.
+
+A defensible production-readiness claim is:
+
+> **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.**
+
+That interpretation matches modern secure-development and reliability practice: NIST’s SSDF aims to reduce vulnerabilities and mitigate the impact of vulnerabilities that remain undetected, while SRE practice uses measurable service-level objectives and error budgets rather than an unsupported promise of perfect uptime. ([csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/218/final))
+
+This checklist is technology-neutral. The complete review begins with the [16-phase engineering lifecycle](../engineering/00-overview.md) and ends with this production gate. The standards snapshot was reviewed on **August 15, 2026** and includes ISO/IEC/IEEE 12207:2026, SWEBOK Guide V4.0, ISO/IEC 25010:2023, NIST SSDF 1.1, OWASP ASVS, WCAG 2.2, SLSA 1.2, NIST SP 800-63 Revision 4, and NIST SP 800-61 Revision 3. See [references and scope](../references.md).
+
+---

package/bin/docs/checklists/01-release-foundations.md

@@ -0,0 +1,91 @@
+# Release foundations
+
+> Define what readiness means, stop unsafe launches early, and identify the exact release under review.
+
+Sections 1–3 of the master checklist. For each applicable item, capture status, owner, evidence, release, environment, reviewer, and evidence age.
+
+## 1. How to operate this checklist
+
+For **every checkbox**, record:
+
+- **Status:** Pass, Fail, Blocked, or Not Applicable.
+- **Applicability rationale:** especially for every Not Applicable item.
+- **Owner:** one accountable person, not just a team name.
+- **Evidence:** test report, log, screenshot, query, configuration export, code review, architecture decision, contract, drill report, or monitoring link.
+- **Tested release:** commit, tag, artifact digest, image digest, configuration version, database migration version, and feature-flag state.
+- **Environment:** exact environment in which the evidence was collected.
+- **Reviewer:** someone other than the implementer for material controls.
+- **Evidence date and expiry:** security scans, accessibility audits, capacity tests, and restore tests become stale.
+- **Exception:** risk owner, justification, compensating control, monitoring, remediation date, and automatic expiry.
+
+Rules:
+
+- A Not Applicable result without a written reason is a failure.
+- A release change made after evidence was captured invalidates every affected result.
+- Do not calculate readiness by averaging scores. One serious failure can outweigh hundreds of passing items.
+- Conditional sections become mandatory whenever their triggering feature, data type, user group, jurisdiction, or risk exists.
+- Risk acceptance is not the same as fixing a problem. It must be explicit, time-bounded, visible, and owned.
+- Evidence must cover the **actual production artifact and production configuration**, not merely a developer’s branch or an earlier build.
+
+---
+
+## 2. Immediate no-go conditions
+
+The release must not proceed while any of these is true:
+
+- [ ] **PRC-02-001** — A critical user journey has not been tested successfully end to end.
+- [ ] **PRC-02-002** — Authentication, authorization, administrative access, or tenant isolation has not been independently verified.
+- [ ] **PRC-02-003** — A known critical vulnerability or relevant known-exploited vulnerability remains unmitigated.
+- [ ] **PRC-02-004** — Production secrets, signing keys, credentials, tokens, or personal data have been exposed.
+- [ ] **PRC-02-005** — A destructive or irreversible data migration has not been rehearsed against representative data.
+- [ ] **PRC-02-006** — Backup restoration has not been demonstrated within the required recovery objectives.
+- [ ] **PRC-02-007** — Rollback or safe roll-forward has not been demonstrated.
+- [ ] **PRC-02-008** — Expected peak load, burst load, or dependency-failure behavior is unknown.
+- [ ] **PRC-02-009** — The release cannot meet its approved reliability objectives under expected operating conditions.
+- [ ] **PRC-02-010** — Monitoring cannot detect failure of critical user journeys.
+- [ ] **PRC-02-011** — No qualified person is available and authorized to respond during and immediately after launch.
+- [ ] **PRC-02-012** — Required incident-response, escalation, customer-communication, or breach-notification procedures do not exist.
+- [ ] **PRC-02-013** — A mandatory legal, privacy, payment, accessibility, safety, or contractual requirement is unmet.
+- [ ] **PRC-02-014** — The production artifact cannot be traced to reviewed source, dependencies, build process, tests, and approval.
+- [ ] **PRC-02-015** — An unsupported or end-of-life runtime, operating system, database, library, service, or protocol is required for operation.
+- [ ] **PRC-02-016** — Known data corruption, cross-user disclosure, cross-tenant access, duplicate charging, or irreversible financial risk remains possible without a tested control.
+- [ ] **PRC-02-017** — A single person, credential, machine, region, provider, or undocumented manual procedure is the only recovery path.
+- [ ] **PRC-02-018** — Evidence was collected before material changes that have not been retested.
+- [ ] **PRC-02-019** — A release blocker has been relabeled, suppressed, or accepted without an accountable risk owner.
+- [ ] **PRC-02-020** — The team cannot describe concrete stop, rollback, and incident-declaration criteria before deployment begins.
+
+Vulnerability priority should not be based on a raw severity score alone. Exploit activity, asset exposure, business impact, local controls, and environmental context must be considered; FIRST’s CVSS guidance specifically recommends enriching base scores with threat and environmental information. ([first.org](https://www.first.org/cvss/v4.0/implementation-guide))
+
+---
+
+## 3. Release control record
+
+### 3.1 Release identity
+
+- [ ] **PRC-03-001** — Assign a unique release identifier.
+- [ ] **PRC-03-002** — Record the exact source commit or commits.
+- [ ] **PRC-03-003** — Record the immutable application artifact digest.
+- [ ] **PRC-03-004** — Record every deployable service, worker, scheduled job, frontend bundle, and infrastructure component included.
+- [ ] **PRC-03-005** — Record database schema and migration versions.
+- [ ] **PRC-03-006** — Record production configuration versions.
+- [ ] **PRC-03-007** — Record feature flags and their intended launch states.
+- [ ] **PRC-03-008** — Record third-party service and API versions relied upon.
+- [ ] **PRC-03-009** — Record the intended production regions, accounts, projects, clusters, and domains.
+- [ ] **PRC-03-010** — Record the target deployment date and change window.
+- [ ] **PRC-03-011** — Record the previous known-good release and rollback artifact.
+- [ ] **PRC-03-012** — Freeze or formally track changes after the readiness evidence snapshot.
+
+### 3.2 Scope
+
+- [ ] **PRC-03-013** — List every user-facing domain and subdomain.
+- [ ] **PRC-03-014** — List every API, webhook, callback, streaming connection, and machine interface.
+- [ ] **PRC-03-015** — List background workers, queues, scheduled tasks, batch processes, and administrative tools.
+- [ ] **PRC-03-016** — List databases, object stores, search indexes, caches, message brokers, analytics stores, and backup locations.
+- [ ] **PRC-03-017** — List external identity, payment, email, SMS, analytics, advertising, support, logging, CDN, and infrastructure providers.
+- [ ] **PRC-03-018** — List all user types, administrative roles, service accounts, and external actors.
+- [ ] **PRC-03-019** — List supported countries, languages, currencies, time zones, browsers, devices, and accessibility targets.
+- [ ] **PRC-03-020** — List all data classifications and regulated data handled.
+- [ ] **PRC-03-021** — List all excluded components and explain why they are outside the release assessment.
+- [ ] **PRC-03-022** — Identify every shared platform or dependency that can affect the app even though another team operates it.
+
+---

package/bin/docs/checklists/02-product-risk-architecture.md

@@ -0,0 +1,136 @@
+# Product, risk, and architecture
+
+> Align business intent, accountable ownership, risk tolerance, and system understanding.
+
+Sections 4–6 of the master checklist. For each applicable item, capture status, owner, evidence, release, environment, reviewer, and evidence age.
+
+## 4. Product and business readiness
+
+### 4.1 Product definition
+
+- [ ] **PRC-04-001** — The problem being solved and intended users are documented.
+- [ ] **PRC-04-002** — Release scope, non-goals, and deferred features are explicit.
+- [ ] **PRC-04-003** — Every feature has testable acceptance criteria.
+- [ ] **PRC-04-004** — Critical user journeys are ranked by business and user impact.
+- [ ] **PRC-04-005** — Critical journeys include onboarding, normal use, error recovery, account recovery, cancellation, and deletion where applicable.
+- [ ] **PRC-04-006** — Product behavior for unavailable dependencies and partial failure is specified.
+- [ ] **PRC-04-007** — Product behavior for empty, malformed, incomplete, stale, or conflicting data is specified.
+- [ ] **PRC-04-008** — User-visible terminology is consistent.
+- [ ] **PRC-04-009** — Pricing, entitlements, quotas, billing rules, and plan limits are unambiguous.
+- [ ] **PRC-04-010** — Cancellation, refund, reversal, dispute, and undo behavior is defined.
+- [ ] **PRC-04-011** — Expected customer support obligations are documented.
+- [ ] **PRC-04-012** — Service hours, maintenance expectations, SLOs, SLAs, and contractual commitments are aligned.
+- [ ] **PRC-04-013** — The launch does not make claims that the implemented product cannot substantiate.
+- [ ] **PRC-04-014** — Product management has accepted the final behavior of critical journeys.
+
+### 4.2 Launch objectives
+
+- [ ] **PRC-04-015** — Define measurable launch success criteria.
+- [ ] **PRC-04-016** — Define measurable launch failure and rollback criteria.
+- [ ] **PRC-04-017** — Define adoption, conversion, quality, reliability, support, and safety indicators.
+- [ ] **PRC-04-018** — Define the observation period before declaring the launch complete.
+- [ ] **PRC-04-019** — Define who has authority to pause, continue, expand, or roll back the launch.
+- [ ] **PRC-04-020** — Establish expected traffic and customer cohorts.
+- [ ] **PRC-04-021** — Establish whether the launch is internal, private, regional, percentage-based, invitation-only, or public.
+- [ ] **PRC-04-022** — Ensure marketing, sales, support, and operations use the same release date and scope.
+- [ ] **PRC-04-023** — Ensure help content, screenshots, pricing pages, documentation, and legal text match the released behavior.
+- [ ] **PRC-04-024** — Ensure customers are notified of breaking changes, downtime, migrations, or changed data use where required.
+
+---
+
+## 5. Governance, ownership, and risk
+
+### 5.1 Ownership
+
+- [ ] **PRC-05-001** — Every production service has a named business owner.
+- [ ] **PRC-05-002** — Every production service has a named engineering owner.
+- [ ] **PRC-05-003** — Every data set has an accountable data owner.
+- [ ] **PRC-05-004** — Every security-sensitive component has a security contact.
+- [ ] **PRC-05-005** — Every third-party integration has an owner.
+- [ ] **PRC-05-006** — Every operational dashboard, alert, and runbook has an owner.
+- [ ] **PRC-05-007** — Every scheduled job and background process has an owner.
+- [ ] **PRC-05-008** — Ownership remains valid during holidays, leave, and personnel changes.
+- [ ] **PRC-05-009** — Escalation paths include primary, secondary, management, security, privacy/legal, and provider escalation contacts.
+- [ ] **PRC-05-010** — Offboarding and role-change processes remove or adjust access promptly.
+
+### 5.2 Risk assessment
+
+- [ ] **PRC-05-011** — Classify confidentiality impact.
+- [ ] **PRC-05-012** — Classify integrity impact.
+- [ ] **PRC-05-013** — Classify availability impact.
+- [ ] **PRC-05-014** — Classify privacy impact.
+- [ ] **PRC-05-015** — Classify financial and fraud impact.
+- [ ] **PRC-05-016** — Classify physical, psychological, societal, and user-safety impact.
+- [ ] **PRC-05-017** — Classify regulatory and contractual impact.
+- [ ] **PRC-05-018** — Classify reputational and customer-trust impact.
+- [ ] **PRC-05-019** — Identify likely attackers, abusive users, insiders, compromised accounts, automated agents, and accidental failure sources.
+- [ ] **PRC-05-020** — Identify foreseeable misuse and abuse cases, not only intended use.
+- [ ] **PRC-05-021** — Maintain a release-specific risk register.
+- [ ] **PRC-05-022** — Give each risk an owner, likelihood, impact, treatment, evidence, and review date.
+- [ ] **PRC-05-023** — Record accepted residual risk and the person authorized to accept it.
+- [ ] **PRC-05-024** — Review high-impact assumptions with independent subject-matter experts.
+- [ ] **PRC-05-025** — Verify that launch scope remains inside the organization’s risk appetite.
+- [ ] **PRC-05-026** — Ensure risk exceptions cannot remain open indefinitely.
+- [ ] **PRC-05-027** — Ensure compensating controls are tested rather than merely described.
+
+### 5.3 Control framework
+
+- [ ] **PRC-05-028** — Map applicable security controls to a recognized verification standard.
+- [ ] **PRC-05-029** — Map applicable privacy controls to legal and organizational requirements.
+- [ ] **PRC-05-030** — Map accessibility requirements to the selected WCAG conformance target.
+- [ ] **PRC-05-031** — Map operational controls to SLO, incident, continuity, and recovery requirements.
+- [ ] **PRC-05-032** — Map contractual controls to customer, processor, provider, and partner agreements.
+- [ ] **PRC-05-033** — Identify conflicts between product requirements, legal requirements, and technical controls.
+- [ ] **PRC-05-034** — Document how conflicts were resolved and who approved the resolution.
+- [ ] **PRC-05-035** — Apply separation of duties to high-impact changes and approvals.
+- [ ] **PRC-05-036** — Periodically review whether the selected control level still matches the app’s risk.
+
+---
+
+## 6. Architecture and system understanding
+
+- [ ] **PRC-06-001** — Maintain an up-to-date system-context diagram.
+- [ ] **PRC-06-002** — Maintain component and deployment diagrams.
+- [ ] **PRC-06-003** — Maintain end-to-end data-flow diagrams.
+- [ ] **PRC-06-004** — Mark trust boundaries explicitly.
+- [ ] **PRC-06-005** — Mark Internet-facing and externally reachable interfaces.
+- [ ] **PRC-06-006** — Mark administrative and support interfaces.
+- [ ] **PRC-06-007** — Mark where authentication and authorization decisions occur.
+- [ ] **PRC-06-008** — Mark encryption and decryption boundaries.
+- [ ] **PRC-06-009** — Mark where sensitive data is collected, transformed, stored, cached, logged, exported, backed up, and deleted.
+- [ ] **PRC-06-010** — Mark all third-party data transfers.
+- [ ] **PRC-06-011** — Identify every stateful component.
+- [ ] **PRC-06-012** — Identify every asynchronous boundary and queue.
+- [ ] **PRC-06-013** — Identify common dependencies and shared failure domains.
+- [ ] **PRC-06-014** — Identify single points of failure.
+- [ ] **PRC-06-015** — Identify control-plane dependencies needed during incidents or recovery.
+- [ ] **PRC-06-016** — Identify circular and hidden dependency chains.
+- [ ] **PRC-06-017** — Document required consistency, ordering, durability, and freshness properties.
+- [ ] **PRC-06-018** — Document architectural invariants that must never be violated.
+- [ ] **PRC-06-019** — Document expected failure behavior for every critical dependency.
+- [ ] **PRC-06-020** — Record material architecture decisions and rejected alternatives.
+- [ ] **PRC-06-021** — Update diagrams whenever the release changes data flow, trust, topology, or dependencies.
+- [ ] **PRC-06-022** — Verify the documented architecture against the deployed environment rather than assuming documentation is accurate.
+
+### 6.1 Threat and abuse modeling
+
+- [ ] **PRC-06-023** — Perform a threat model for the actual release scope.
+- [ ] **PRC-06-024** — Include all trust boundaries, actors, entry points, data stores, and external systems.
+- [ ] **PRC-06-025** — Model spoofing and identity attacks.
+- [ ] **PRC-06-026** — Model unauthorized modification and integrity attacks.
+- [ ] **PRC-06-027** — Model information disclosure and privacy attacks.
+- [ ] **PRC-06-028** — Model denial of service and resource exhaustion.
+- [ ] **PRC-06-029** — Model privilege escalation.
+- [ ] **PRC-06-030** — Model repudiation and inadequate accountability.
+- [ ] **PRC-06-031** — Model business-logic abuse.
+- [ ] **PRC-06-032** — Model insider and compromised-administrator threats.
+- [ ] **PRC-06-033** — Model dependency and build-system compromise.
+- [ ] **PRC-06-034** — Model tenant-escape and cross-customer attacks.
+- [ ] **PRC-06-035** — Model automation, scraping, spam, fraud, and economic abuse.
+- [ ] **PRC-06-036** — Model recovery-system and backup attacks.
+- [ ] **PRC-06-037** — Model support-channel and account-recovery social engineering.
+- [ ] **PRC-06-038** — Convert identified threats into requirements and tests.
+- [ ] **PRC-06-039** — Revisit the threat model after material design or scope changes.
+- [ ] **PRC-06-040** — Obtain independent review for high-value or high-risk systems.
+
+---

package/bin/docs/checklists/03-source-build-supply-chain.md

@@ -0,0 +1,97 @@
+# Source, build, and supply chain
+
+> Protect source changes, build integrity, dependencies, provenance, and licensing.
+
+Sections 7–9 of the master checklist. For each applicable item, capture status, owner, evidence, release, environment, reviewer, and evidence age.
+
+## 7. Source control and change management
+
+- [ ] **PRC-07-001** — One authoritative source repository is identified.
+- [ ] **PRC-07-002** — Repository access uses individual identities rather than shared accounts.
+- [ ] **PRC-07-003** — Strong authentication is required for repository access.
+- [ ] **PRC-07-004** — Access follows least privilege.
+- [ ] **PRC-07-005** — Protected branches prevent unreviewed direct changes.
+- [ ] **PRC-07-006** — Material changes require independent review.
+- [ ] **PRC-07-007** — Critical code areas require designated reviewers.
+- [ ] **PRC-07-008** — Review cannot be bypassed silently by administrators.
+- [ ] **PRC-07-009** — Merge requirements include the required automated checks.
+- [ ] **PRC-07-010** — Security-sensitive changes receive appropriate specialist review.
+- [ ] **PRC-07-011** — Infrastructure, pipeline, authorization, cryptography, payment, and migration changes receive heightened review.
+- [ ] **PRC-07-012** — Changes are traceable from requirement or issue to code, review, build, artifact, and deployment.
+- [ ] **PRC-07-013** — Commit history and release tags are protected against unauthorized rewriting.
+- [ ] **PRC-07-014** — Secret scanning covers current changes and repository history.
+- [ ] **PRC-07-015** — Large binaries, generated files, and vendored code are controlled.
+- [ ] **PRC-07-016** — Generated code has a documented trusted source and regeneration process.
+- [ ] **PRC-07-017** — Emergency changes follow a documented break-glass process and receive retrospective review.
+- [ ] **PRC-07-018** — Repository backup and recovery have been tested.
+- [ ] **PRC-07-019** — Departed personnel and obsolete automation identities no longer have access.
+- [ ] **PRC-07-020** — Repository webhooks, apps, bots, and deploy keys are inventoried and restricted.
+
+---
+
+## 8. Build, CI/CD, and artifact integrity
+
+SLSA 1.2 organizes software supply-chain assurance around verifiable provenance and build integrity. The checklist below applies those outcomes without requiring a particular build platform. ([slsa.dev](https://slsa.dev/spec/v1.2/))
+
+- [ ] **PRC-08-001** — Builds run from reviewed source.
+- [ ] **PRC-08-002** — Builds are automated and repeatable.
+- [ ] **PRC-08-003** — A clean build produces equivalent output from the same declared inputs.
+- [ ] **PRC-08-004** — Build inputs and dependency versions are pinned sufficiently to prevent unexpected substitution.
+- [ ] **PRC-08-005** — Builds fail closed when required verification cannot run.
+- [ ] **PRC-08-006** — The production artifact is built once and promoted, not independently rebuilt in each environment.
+- [ ] **PRC-08-007** — Deployable artifacts are immutable.
+- [ ] **PRC-08-008** — Every artifact has a cryptographic digest.
+- [ ] **PRC-08-009** — Build provenance records source, builder, inputs, commands or workflow, time, and output digest.
+- [ ] **PRC-08-010** — Artifact signatures or attestations are verified before deployment.
+- [ ] **PRC-08-011** — Build identities and signing keys use least privilege.
+- [ ] **PRC-08-012** — Build and signing keys are stored outside source code and build output.
+- [ ] **PRC-08-013** — Build runners are patched and isolated appropriately.
+- [ ] **PRC-08-014** — Untrusted contribution workflows cannot access production secrets.
+- [ ] **PRC-08-015** — Pull-request builds cannot overwrite trusted release artifacts.
+- [ ] **PRC-08-016** — CI jobs have minimum required network, repository, cloud, and registry permissions.
+- [ ] **PRC-08-017** — Pipeline definitions receive the same review protection as application code.
+- [ ] **PRC-08-018** — Required unit, integration, security, policy, and packaging checks cannot be skipped silently.
+- [ ] **PRC-08-019** — Failed or canceled checks cannot be misrepresented as passed.
+- [ ] **PRC-08-020** — Artifact registries enforce authentication, authorization, immutability, and retention.
+- [ ] **PRC-08-021** — The previous known-good artifact remains available.
+- [ ] **PRC-08-022** — Build logs do not expose secrets or sensitive source material.
+- [ ] **PRC-08-023** — Build caches cannot substitute unverified or cross-trust artifacts.
+- [ ] **PRC-08-024** — Release tags, artifacts, provenance, and deployment records agree.
+- [ ] **PRC-08-025** — Compromise of the build platform has a documented containment and recovery procedure.
+- [ ] **PRC-08-026** — A supply-chain incident drill has tested revocation, rebuild, resigning, and redeployment.
+
+---
+
+## 9. Dependencies, SBOM, and licenses
+
+A software bill of materials should cover the complete release, while vulnerability prioritization should account for known exploitation and deployment context rather than merely counting CVEs. ([cisa.gov](https://www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom))
+
+- [ ] **PRC-09-001** — Generate an SBOM for every released application artifact.
+- [ ] **PRC-09-002** — Include direct and transitive components.
+- [ ] **PRC-09-003** — Include runtime, operating-system, container, client, server, plugin, model, and embedded components as applicable.
+- [ ] **PRC-09-004** — Distinguish build-only, development-only, optional, and runtime dependencies.
+- [ ] **PRC-09-005** — Record exact versions, package identifiers, sources, hashes, and relationships.
+- [ ] **PRC-09-006** — Record license information and required notices.
+- [ ] **PRC-09-007** — Link the SBOM to the released artifact digest.
+- [ ] **PRC-09-008** — Verify the SBOM against the final packaged artifact.
+- [ ] **PRC-09-009** — Ensure no unexpected undeclared components are present.
+- [ ] **PRC-09-010** — Remove unused dependencies.
+- [ ] **PRC-09-011** — Remove unsupported and end-of-life dependencies.
+- [ ] **PRC-09-012** — Check whether dependencies come from intended publishers and registries.
+- [ ] **PRC-09-013** — Protect against dependency confusion, namespace collision, and typographical substitution.
+- [ ] **PRC-09-014** — Assess maintainer health and abandonment risk for critical dependencies.
+- [ ] **PRC-09-015** — Monitor upstream security advisories.
+- [ ] **PRC-09-016** — Continuously scan released components for newly disclosed vulnerabilities.
+- [ ] **PRC-09-017** — Prioritize vulnerabilities using exploit activity, reachability, exposure, asset criticality, data sensitivity, and compensating controls.
+- [ ] **PRC-09-018** — Check relevant known-exploited-vulnerability catalogs.
+- [ ] **PRC-09-019** — Define remediation targets by actual risk.
+- [ ] **PRC-09-020** — Verify fixes or mitigations after deployment.
+- [ ] **PRC-09-021** — Maintain a process for emergency replacement of a compromised dependency.
+- [ ] **PRC-09-022** — Document ownership of vendored, forked, or internally patched components.
+- [ ] **PRC-09-023** — Test updates before promotion.
+- [ ] **PRC-09-024** — Verify license compatibility among combined components.
+- [ ] **PRC-09-025** — Provide required attributions, source offers, notices, and redistribution terms.
+- [ ] **PRC-09-026** — Ensure proprietary or confidential code is not unintentionally incorporated into distributable artifacts.
+- [ ] **PRC-09-027** — Retain SBOMs for historical releases and incident investigation.
+
+---