CRA Compliance-Officer End-to-End Scenarios

Currency check 2026-10-07: owner paths/source placement verified against 3238bd511a37e199ae99d4f17be2f13eabec8dd7. The supported boundary is /api/offlinekit/v1/exports (src/OfflineKit/StellaOps.OfflineKit.WebService/Program.cs). Re-verify the host mount and owning endpoint extension together. This is source verification; deployment and broader audit coverage are separate evidence. Other dated findings retain their stated dates. Re-verify: rg -n "MapGroup|Map.*Endpoints|AddHostedService" src/OfflineKit/StellaOps.OfflineKit.WebService/Program.cs, then inspect the endpoint extension or library pointer cited at the operation.

Pack: CRA Assurance Packs — claim boundaries manufacturer-self / manufacturer-customer-support

Audience: a manufacturer’s compliance officer preparing certifiable CRA evidence with Stella Ops, plus the QA / Test Automation agents who execute these scenarios. Each scenario is end-to-end: a narrative, the concrete UI route + API calls against the live docker stack, expected assertions, and a claim-boundary note.

These scenarios drive the Playwright spec src/Web/StellaOps.Web/tests/e2e/compliance/cra-compliance-officer.e2e.spec.ts, executed against the live stack with the colocated live-auth fixture (tests/e2e/compliance/live-auth.fixture.ts, real OIDC login → Bearer token → apiRequest/tenantId fixtures) and the dedicated config src/Web/StellaOps.Web/playwright.compliance.config.ts (base https://stella-ops.local, ignoreHTTPSErrors, no mocking, testDir tests/e2e/compliance). The config is modelled on playwright.integrations.config.ts (the live-docker-stack target) and is shared by the sibling NIS2/DORA compliance specs.

Run (AUTHOR ONLY — a later wave executes these one-by-one):

cd src/Web/StellaOps.Web
PLAYWRIGHT_BASE_URL=https://stella-ops.local \
STELLAOPS_ADMIN_USER=admin STELLAOPS_ADMIN_PASS='<the password your installer printed>' \
  npx playwright test --config=playwright.compliance.config.ts \
    tests/e2e/compliance/cra-compliance-officer.e2e.spec.ts

Each test.describe is tagged with its scenario id (@cra-s1…@cra-s6); run a single scenario with --grep @cra-s3.

Two packs, never one “CRA mode”

CRA support is split into two optional Assurance packs with different manufacturer responsibilities. The scenarios keep them distinct and keep the two readiness-flag pairs un-conflated:

Two independent readiness splits the specs must assert separately:

• ExportCenter reports signedExportReady (local signed bundle storage + signing key/provider + tenant export trust roots) and livePublicationReady (public mailbox / intake key / rotation roles / support-lifecycle metadata) separately. A profile can be signedExportReady=true while livePublicationReady=false. Response shape: GET /api/offlinekit/v1/exports/assurance/profiles/{id}/readiness (AssuranceExportReadinessResponse).
• Notify reports Article 14 timeline readiness as operatorHandoffReady (the default: produce-and-sign local handoff) and autoSubmitReady (explicit opt-in, gated on fresh-auth + tenant SRP config). autoSubmitReady=true is not a live regulator receipt. Response shape: GET /api/v1/assurance/reporting-timeline-profiles/cra.article14.incident/readiness (AssuranceReportingProfileReadiness).

Forbidden product copy (never assert/emit; see docs/compliance/README.md→ Forbidden product copy): “CRA compliant mode”, “Turn on CRA compliant mode”, or any copy collapsing the two packs.

Live routes used (verified against src/)

Current export prefix composition is verified in src/OfflineKit/StellaOps.OfflineKit.WebService/Program.cs and AssuranceExportEndpoints. Notify maps the reporting-timeline and profile endpoints in src/Notify/StellaOps.Notify.WebService/Program.cs; both hosts publish endpoint metadata when Router registration is enabled. An absent static rewrite in Gateway configuration does not establish route unavailability. Deployment and gateway reachability require current probes.

Profile id constants (verified)

• ExportCenter: cra.technical-file (adapter cra:tech-file, schema cra-tech-file-v1), cra.conformity-dossier (adapter cra:conformity-dossier, schema conformity-dossier-v1); both pack cra.technical-documentation, framework cra, readinessPrerequisites include cra.technical-documentation.signed-export and cra.product-security.publication.
• Notify: cra.article14.incident (framework cra, pack cra.product-security, claim manufacturer-self, payload contract enisa-incident-reporting-v1), milestones early-warning (PT24H), notification (PT72H), final-report (P14D).

Scenario CRA-S1 — CRA Technical File export (Annex VII)

Narrative. The compliance officer must assemble the Annex VII technical documentation file for a release the company places on the EU market. They first confirm Stella advertises the cra.technical-file Assurance profile, that it is deterministic + signed (offline-verifiable), and that ExportCenter reports whether the signed local bundle can be produced (signedExportReady) independently of any public publication.

Live drive (API).

1. GET /api/offlinekit/v1/exports/assurance/profiles?frameworkId=cra -> list MUST contain cra.technical-file and cra.conformity-dossier only (framework filter excludes nis2/dora).
2. GET /api/offlinekit/v1/exports/assurance/profiles/cra.technical-file -> descriptor.
3. GET /api/offlinekit/v1/exports/assurance/profiles/cra.technical-file/readiness → readiness with the two-flag split.

Expected assertions.

• Descriptor: profileId == "cra.technical-file", frameworkId == "cra", packId == "cra.technical-documentation", adapterId == "cra:tech-file", schemaId == "cra-tech-file-v1", signingRequired == true, supportsOfflineVerification == true, offlineVerifier.payloadTypeId is the CRA tech-file EU signing payload id, and compatibilityRoutes includes "stella export cra-tech-file".
• Readiness: signedExportReady is a boolean; livePublicationReady is present and is a boolean (NOT null) for CRA profiles; secretValuesExposed == false; no reason summary leaks a secret/path. reasonCodes is a sorted string array. If signedExportReady == false, the blocking reasons are drawn from {storage-root-missing, signing-key-missing, signing-provider-missing, tenant-export-trust-roots-missing} and carry category signed-export.

Determinism + signature (Tier 2d, referenced — not run by these specs). The byte-identical bundle hash + DSSE/HMAC signature proof lives in the adapter test project src/OfflineKit/__Tests/StellaOps.ExportCenter.Adapters.Cra.Tests/ (CraTechFileAdapterTests, trait Intent=Regulatory) and the CLI stella export cra-tech-file / stella verify cra-tech-file (src/Cli/.../CraTechFileCommandTests). OfflineKit’s HTTP producer calls the production-signed adapter in current source. A discovery check alone does not prove production, deterministic bytes, or signature validation in the deployed stack; a current production/readback/download run needs separate evidence. For a discovery check, retain the descriptor assertions: signingRequired, supportsOfflineVerification, and the fixed schemaId/adapterId. Record the bundle-hash proof separately.

Claim boundary. manufacturer-self when the product is Stella itself, else manufacturer-customer-support. The export publishes nothing and implies no conformity route. Do not present readiness as “CRA compliant”.

Scenario CRA-S2 — Conformity dossier (Module A default)

Narrative. Having a technical file, the officer assembles the conformity dossier, which composes the Annex VII technical file (embedded at tech-file/cra-tech-file.tar.gz) with the selected conformity route overlay (Module A internal production control is the CRA-Q5 default for Stella; B+C and H remain available for customer products).

Live drive (API).

1. GET /api/offlinekit/v1/exports/assurance/profiles/cra.conformity-dossier.
2. GET /api/offlinekit/v1/exports/assurance/profiles/cra.conformity-dossier/readiness.

Expected assertions.

• Descriptor: profileId == "cra.conformity-dossier", packId == "cra.technical-documentation", adapterId == "cra:conformity-dossier", schemaId == "conformity-dossier-v1", signingRequired == true, supportsOfflineVerification == true. deterministicInputs MUST include "cra.technical-file.bundle" (the dossier references / embeds the technical file). compatibilityRoutes includes "stella export conformity-dossier".
• Readiness shares the CRA technical-documentation signed-export checks and reports livePublicationReady separately, exactly like S1.

Structure proof (Tier 2d, referenced). That the dossier index references the embedded technical file (techFile.{path,indexHash,bundleHash,sizeBytes}), declared controls + evidence links (SBOM/advisory), and Module-A overlay is asserted byte-deterministically in src/OfflineKit/__Tests/StellaOps.ExportCenter.Adapters.Cra.Tests/ (ConformityBuild_ModuleA_ProducesDeterministicSelfAssessmentBundle) and via stella export conformity-dossier --module A. OfflineKit’s HTTP producer builds a signed inner technical file and assembles the conformity dossier in current source. The dossier index remains not-signed; discovery alone proves neither production nor signature acceptance in the deployed stack.

Claim boundary. Same as S1. The dossier is an evidence export; it does not make Stella the notified body and does not auto-file.

Scenario CRA-S3 — Article 14 incident reporting (24h / 72h / 14d)

Narrative. An actively-exploited vulnerability is confirmed in the manufacturer’s product. The officer needs the CRA Article 14 reporting timeline: early warning (24h), vulnerability notification (72h), final report (14 days). The default posture must be a locally signed operator handoff — Stella must NOT imply it auto-files with ENISA/an authority.

Live drive (API).

1. GET /api/v1/assurance/reporting-timeline-profiles?frameworkId=cra → list contains cra.article14.incident.
2. GET /api/v1/assurance/reporting-timeline-profiles/cra.article14.incident → profile with milestones.
3. GET /api/v1/assurance/reporting-timeline-profiles/cra.article14.incident/readiness → two-flag readiness.

Expected assertions.

• Profile: timelineProfileId == "cra.article14.incident", frameworkId == "cra", packId == "cra.product-security", claimBoundary == "manufacturer-self", payloadContract == "enisa-incident-reporting-v1", signingRequired == true.
• Milestones (by milestoneId): early-warning → dueWithin == "PT24H"; notification → "PT72H"; final-report → "P14D". The CRA 14-day final report (P14D) differs from NIS2/DORA P1M — assert the exact ISO-8601 duration.
• operatorApproval.defaultPosture == "produce-and-sign-handoff", autoSubmitAvailable == true, autoSubmitDefault == false, freshAuthRequired == true. Channels include enisa-cra.
• Readiness: operatorHandoffReady and autoSubmitReady are present as separate booleans. The default is operator handoff: when the profile is not fully configured, operatorHandoffReady == false and the operatorHandoffReasonCodes come from {publication-handoff-not-configured, operator-approval-missing, pgp-recipient-key-missing, webhook-signing-key-missing, csirt-destination-missing}. autoSubmitReasonCodes additionally carries auto-submit-disabled whenever auto-submit is not explicitly enabled — proving auto-submit is opt-in. autoSubmitReady MUST never be true while operatorHandoffReady is false (auto-submit reasons are a superset of handoff reasons). secretValuesExposed == false.

Claim boundary. manufacturer-self for Stella-as-manufacturer. For customer products the customer remains the reporting party; Stella provides timeline control + signed handoff packets only. Auto-submit is not a live regulator receipt.

Scenario CRA-S4 — Publication preflight (signed export ready ≠ live publication)

Narrative. The officer has a signed local technical-file/advisory artifact but must understand that public product-security publication (mailbox, intake key, advisory feed route, support-lifecycle metadata) is a separate gate. A blocked public publication preflight must NOT block local signed export, and the public well-known metadata document must fail closed when not fully configured.

Live drive (API + public route).

1. GET /api/offlinekit/v1/exports/assurance/profiles/cra.technical-file/readiness — observe signedExportReady and the SEPARATE livePublicationReady.
2. GET /.well-known/stella-product-security.json (anonymous, gateway root, Router-owned, fail-closed).
3. GET /.well-known/security.txt (anonymous).

Expected assertions.

• The two flags are reported independently. The spec asserts the split exists (signedExportReady present AND livePublicationReady present as a boolean), and that when livePublicationReady == false the live-publication reasons are drawn from {security-mailbox-unverified, intake-key-expired-or-missing, rotation-roles-missing, support-lifecycle-metadata-missing} with category live-publication — and that signedExportReady is evaluated independently of those (signed export is gated only on signed-export category reasons).
• /.well-known/stella-product-security.json: either 200 with a JSON metadata document (when configured) or a fail-closed status (e.g. 404/503) — the route is anonymous and MUST NOT 500, and MUST NOT leak private keys/mailbox credentials. When 200, the body is JSON and any csafFeedUrl is an HTTPS URL.
• /.well-known/security.txt: anonymous, MUST NOT 500.
• Claim-boundary copy guard: no asserted/observed text contains “CRA compliant mode”.

Claim boundary. manufacturer-self. The live-publication line is about Stella-as-manufacturer publication; it must never tell a customer tenant to configure Stella’s manufacturer mailbox for their own local evidence packs.

Scenario CRA-S5 — Pack separation invariant (no “CRA mode”)

Narrative. A cross-cutting guard: the two CRA packs are distinct surfaces with distinct claim boundaries, and the two readiness-flag pairs are never collapsed.

Live drive (API). Reuse S1 + S3 responses.

Expected assertions.

• The Technical Documentation pack id (cra.technical-documentation, on the export profiles) is distinct from the Product Security pack id (cra.product-security, on the Article 14 timeline profile). The export profiles never carry cra.product-security as packId, and the timeline profile never carries cra.technical-documentation.
• The export readiness uses signedExportReady/livePublicationReady; the reporting readiness uses operatorHandoffReady/autoSubmitReady. No response mixes the two flag names (the export readiness JSON has no operatorHandoffReady; the reporting readiness JSON has no signedExportReady).
• Claim boundaries: export profiles’ CRA claim is technical-documentation; the Article 14 profile claim is manufacturer-self.

Scenario CRA-S6 — Assurance Console shows two distinct CRA packs (UI)

Narrative. The compliance officer opens the operator-facing pack-discovery surface and must see the CRA Product Security Pack rendered as its own card, with no “CRA compliant mode” copy and no collapsed single pack.

Live drive (UI). Navigate /assurance (the canonical pack-discovery surface, Nis2ControlRegisterPageComponent’s sibling assurance shell). Render against live data via the OIDC-authenticated liveAuthPage fixture.

Expected assertions.

• assurance-frameworks-page test id is visible.
• Page body text does NOT contain “cra compliant mode” or “turn on cra”.
• The assurance-pack-cra.product-security card is present and labelled “CRA Product Security Pack”.

Claim boundary. UI copy must use “CRA technical documentation support” / “Manufacturer publication preflight” — never “CRA compliant mode”.

Note: this UI scenario depends on the live /assurance shell exposing the documented data-testids. If those test ids differ in the running build, this is a test-id contract gap to record (do NOT edit shared FE component files).

Gaps noticed (report only — do NOT fix in this wave)

• HTTP production requires its own runtime evidence. The earlier discovery/readiness-only and CLI/library-only observation is superseded by current OfflineKit source: the Assurance API maps POST production, run readback, and bundle download, and the producer handles both CRA profiles. Adapter/CLI tests and discovery receipts do not establish a current deployed production run. Measure the HTTP run and verification separately; preserve the distinction between the signed technical file and the unsigned outer conformity-dossier index.
• Persisted-records gateway reachability is UNVERIFIED here. Notify maps ReportingTimelineEndpoints and refreshes its advertised endpoint metadata. The earlier verdict based only on a missing static Gateway rewrite is superseded. A current authenticated gateway request is required to determine reachability of GET /api/v1/regulatory/reporting-timelines?regime=cra; this source-only currency check executes no such request.
• Readiness depends on stack config. signedExportReady, livePublicationReady, operatorHandoffReady, and autoSubmitReady reflect the live stack’s sealed configuration (export storage/signing/trust-roots; CRA publication mailbox/key/rotation/support-lifecycle; reporting handoff + auto-submit options). The specs therefore assert the structure and the split (both flags present, correct categories, no secret leakage, auto-submit ⊇ handoff reasons) rather than hard-coding a single boolean — the boolean depends on whether the operator has configured those surfaces.