Add unit tests for SBOM ingestion and transformation

- Implement `SbomIngestServiceCollectionExtensionsTests` to verify the SBOM ingestion pipeline exports snapshots correctly.
- Create `SbomIngestTransformerTests` to ensure the transformation produces expected nodes and edges, including deduplication of license nodes and normalization of timestamps.
- Add `SbomSnapshotExporterTests` to test the export functionality for manifest, adjacency, nodes, and edges.
- Introduce `VexOverlayTransformerTests` to validate the transformation of VEX nodes and edges.
- Set up project file for the test project with necessary dependencies and configurations.
- Include JSON fixture files for testing purposes.

docs/dev/31_AUTHORITY_PLUGIN_DEVELOPER_GUIDE.md

@@ -17,11 +17,19 @@ Authority hosts follow a deterministic plug-in lifecycle. The exported diagram (
 3. **Registrar execution** – each assembly is searched for `IAuthorityPluginRegistrar` implementations. Registrars bind options, register services, and optionally queue bootstrap tasks.
 4. **Runtime** – the host resolves `IIdentityProviderPlugin` instances, uses capability metadata to decide which OAuth grants to expose, and invokes health checks for readiness endpoints.
 
-![Authority plug-in lifecycle diagram](../assets/authority/authority-plugin-lifecycle.svg)
-
-_Source:_ `docs/assets/authority/authority-plugin-lifecycle.mmd`
-
-**Data persistence primer:** the standard Mongo-backed plugin stores users in collections named `authority_users_<pluginName>` and lockout metadata in embedded documents. Additional plugins must document their storage layout and provide deterministic collection naming to honour the Offline Kit replication process.
+![Authority plug-in lifecycle diagram](../assets/authority/authority-plugin-lifecycle.svg)
+
+_Source:_ `docs/assets/authority/authority-plugin-lifecycle.mmd`
+
+### 2.1 Component boundaries
+
+The Standard plug-in ships with a small, opinionated surface: configuration is bound during registrar execution, capability metadata feeds the host, and credential/audit flows stay deterministic and offline-friendly. The component view below highlights those boundaries and where operators supply bundles (secrets, offline kits) for air-gapped installs.
+
+![Standard plug-in component topology](../assets/authority/authority-plugin-component.svg)
+
+_Source:_ `docs/assets/authority/authority-plugin-component.mmd`
+
+**Data persistence primer:** the standard Mongo-backed plugin stores users in collections named `authority_users_<pluginName>` and lockout metadata in embedded documents. Additional plugins must document their storage layout and provide deterministic collection naming to honour the Offline Kit replication process.
 
 ## 3. Capability Metadata
 Capability flags let the host reason about what your plug-in supports:
@@ -108,13 +116,25 @@ Capability flags let the host reason about what your plug-in supports:
 - Password guidance:
   - Standard plug-in hashes via `ICryptoProvider` using Argon2id by default and emits PHC-compliant strings. Successful PBKDF2 logins trigger automatic rehashes so migrations complete gradually. See `docs/security/password-hashing.md` for tuning advice.
   - Enforce password policies before hashing to avoid storing weak credentials.
-- Health checks should probe backing stores (e.g., Mongo `ping`) and return `AuthorityPluginHealthResult` so `/ready` can surface issues.
-- When supporting additional factors (e.g., TOTP), implement `SupportsMfa` and document the enrolment flow for resource servers.
-
-## 7. Configuration & Secrets
-- Authority looks for manifests under `etc/authority.plugins/`. Each YAML file maps directly to a plug-in name.
-- Support environment overrides using `STELLAOPS_AUTHORITY_PLUGINS__DESCRIPTORS__<NAME>__...`.
-- Never store raw secrets in git: allow operators to supply them via `.local.yaml`, environment variables, or injected secret files. Document which keys are mandatory.
+- Health checks should probe backing stores (e.g., Mongo `ping`) and return `AuthorityPluginHealthResult` so `/ready` can surface issues.
+- When supporting additional factors (e.g., TOTP), implement `SupportsMfa` and document the enrolment flow for resource servers.
+
+### 6.1 Bootstrap lifecycle
+
+Standard plug-in installs begin with an operator-provided manifest and secrets bundle. The registrar validates those inputs, primes the credential store, and only then exposes the identity surface to the host. Every transition is observable (audit events + telemetry) and deterministic so air-gapped operators can replay the bootstrap evidence.
+
+- Secrets bundles must already contain hashed bootstrap principals. Registrars re-hash only to upgrade algorithms (e.g., PBKDF2 to Argon2id) and log the outcome.
+- `WarmupAsync` should fail fast when Mongo indexes or required secrets are missing; readiness stays `Unhealthy` until the registrar reports success.
+- Audit and telemetry payloads (`authority.plugin.load`) are mirrored into Offline Kits so security reviewers can verify who seeded credentials and when.
+
+![Standard plug-in bootstrap sequence](../assets/authority/authority-plugin-bootstrap-sequence.svg)
+
+_Source:_ `docs/assets/authority/authority-plugin-bootstrap-sequence.mmd`
+
+## 7. Configuration & Secrets
+- Authority looks for manifests under `etc/authority.plugins/`. Each YAML file maps directly to a plug-in name.
+- Support environment overrides using `STELLAOPS_AUTHORITY_PLUGINS__DESCRIPTORS__<NAME>__...`.
+- Never store raw secrets in git: allow operators to supply them via `.local.yaml`, environment variables, or injected secret files. Document which keys are mandatory.
 - Validate configuration as soon as the registrar runs; use explicit error messages to guide operators. The Standard plug-in now enforces complete bootstrap credentials (username + password) and positive lockout windows via `StandardPluginOptions.Validate`.
 - Cross-reference bootstrap workflows with `docs/modules/authority/operations/bootstrap.md` (to be published alongside CORE6) so operators can reuse the same payload formats for manual provisioning.
 - `passwordHashing` inherits defaults from `authority.security.passwordHashing`. Override only when hardware constraints differ per plug-in:

docs/dev/kisa_connector_notes.md

@@ -41,5 +41,7 @@ The messages use structured properties (`Idx`, `Category`, `DocumentId`, `Severi
 - Metrics carry Hangul `category` tags and logging keeps Hangul strings intact; this ensures air-gapped operators can validate native-language content without relying on MT.
 - Fixtures live under `src/Concelier/__Tests/StellaOps.Concelier.Connector.Kisa.Tests/Fixtures/`. Regenerate with `UPDATE_KISA_FIXTURES=1 dotnet test src/Concelier/__Tests/StellaOps.Concelier.Connector.Kisa.Tests/StellaOps.Concelier.Connector.Kisa.Tests.csproj`.
 - The regression suite asserts canonical mapping, state cleanup, and telemetry counters (`KisaConnectorTests.Telemetry_RecordsMetrics`) so QA can track instrumentation drift.
+- When capturing new offline samples, use `scripts/kisa_capture_html.py` to mirror the RSS feed and write `detailDos.do?IDX=…` HTML into `seed-data/kisa/html/`; the SPA now embeds full advisory content in the HTML response while `rssDetailData.do` returns an error page for unauthenticated clients.
+- 2025-11-03: Connector fetches `detailDos.do` HTML during the fetch phase and the parser now extracts vendor/product tables directly from the DOM when JSON detail API payloads are unavailable.
 
 For operator docs, link to this brief when documenting Hangul handling or counter dashboards so localisation reviewers have a single reference point.