QVAC-21554 infra: license/compliance CI gate on qvac (warn-only, SKILL fallback)

[GSServita]

🎯 What problem does this PR solve?

• License / NOTICE / compliance review on PRs relies on a human remembering to run the qv-notice-generate SKILL. It is opt-in, non-blocking, and leaves no durable record, so a disallowed license (AGPL, SSPL, GPL on a runtime path) or a missing attribution can reach a shipped artifact unnoticed.
• The approved Q2 design (tetherto/qvac-actions/docs/license-compliance-ci.md) makes license/compliance a deterministic CI gate on Tier-1 repos with the SKILL demoted to the fallback. This PR is the consumer-side wiring for this repo, the first Tier-1 pilot (QVAC-21554).

📝 How does it solve it?

• .github/workflows/license-compliance.yml: a thin caller (mirroring security-baseline.yml) that delegates to the org reusable workflow public-reusable-license.yml. It runs in warn-only (shadow) mode — findings are annotated on the PR and in the job summary but never block a merge yet.
• .github/license-allowlist.yml: the exception allowlist (empty seed, schema + process documented in-file). .github/CODEOWNERS routes edits to @tetherto/qvac-internal-merge, so exceptions require a Tier-1 reviewer rather than being self-served by the PR author.
• docs/ci/LABELS.md: documents the license-override label (downgrades a High finding for one PR; Critical can never be overridden; the durable record is an allowlist entry).
• .cursor/skills/qv-notice-generate/SKILL.md: demoted to the documented fallback — for novel/unclassifiable licenses, full transitive audits (the gate is manifest-only since lockfiles are gitignored here), and NOTICE authoring.
• docs/devops/TIER-1-SCOPE.md: new scope doc; §B1 defines the license/compliance enforcement surface and resolves the ticket's reference. The full Tier-1 scope lock remains QVAC-19052.

🧪 How was it tested?

• actionlint clean on .github/workflows/license-compliance.yml.
• Reusable workflow + classifier live in tetherto/qvac-actions PR fix npm publish qvac-lib-dl-hyperdrive-integration-test1 #12 (QVAC-21554 feat: canonical license compliance reusable workflow qvac-actions#12); its license-policy.mjs was validated locally against the full fail-vs-warn matrix and is covered by a negative + positive self-test there.
• Warn-only mode means the first real run on this repo cannot block any PR; it only annotates. First end-to-end validation of the caller happens on this PR's own license-compliance run.

🔐 Action pinning

• New reusable-workflow reference, pinned by commit SHA: tetherto/qvac-actions/.github/workflows/public-reusable-license.yml@0f4f710756ffb063d7b81686b84271d6601052ae.
• This is a provisional pin to the qvac-actions feature-branch commit (PR fix npm publish qvac-lib-dl-hyperdrive-integration-test1 #12) so this caller is runnable now. It MUST be repinned to the 0.3.0 release tag's immutable commit SHA (freeze-and-pin convention) once qvac-actions fix npm publish qvac-lib-dl-hyperdrive-integration-test1 #12 merges and the tag is cut. A # pending 0.3.0 comment marks it.

🛡️ Permissions changes

• Scope: new workflow license-compliance.yml — top-level and job license.
• Before: n/a (new workflow).
• After: top-level contents: read; job license widens to contents: read + pull-requests: write.
• Justification: contents: read for checkout + the dependency-review graph API; pull-requests: write only to upsert the single summary comment. No write to code. Uses plain pull_request (never pull_request_target), so fork PRs stay read-only and secret-free.

[github-actions]

Review Status

Current Status: ❌ PENDING
Approvals so far: none

Pending reviews: Needs 1 Management or Team Lead, and 1 more from Management, Team Lead, or Member.

[github-actions]

License compliance — findings detected (warn-only)

Critical: 0 · High: 1 · Medium: 0

Dependency	License	Scope	Severity	Outcome
tetherto/qvac-actions/.github/workflows/public-reusable-license.yml@ce61672c6a49861ee5ff2e5e6617e4f0df665d37	(none detected)	runtime	High	blocks

How to resolve a blocking finding:

• Remove or replace the disallowed dependency, or
• If the license is genuinely acceptable, run the compliance SKILL and record the decision in .github/license-allowlist.yml (CODEOWNERS-reviewed), or
• For a one-off, a maintainer can apply the license-override label (High findings only; Critical cannot be overridden).

Warn-only (shadow) mode — this check does not block merges yet.

Updated automatically by the canonical license compliance workflow.

NOTICE presence (advisory)

Missing NOTICE (advisory, does not block):

• ./packages/embed-llamacpp/benchmarks/server
• ./packages/embed-llamacpp/benchmarks/performance
• ./packages/ggml-coload-smoke
• ./packages/llm-llamacpp/benchmarks/server
• ./packages/llm-llamacpp/benchmarks/performance
• ./packages/fabric/test/integration
• ./packages/transcription-whispercpp/benchmarks/server
• ./packages/transcription-parakeet/benchmarks/server
• ./packages/sdk/e2e
• ./packages/vla-ggml/sim/server
• ./.github/actions/release-merge-guard
• ./docs/website

[Proletter]

Reviewed against QVAC-21554 ("License / compliance enforced in CI on Tier-1 — SKILL becomes fallback"). This consumer-side wiring, plus qvac-actions#12 (the reusable engine), aligns well with the ticket: CI gate on the first Tier-1 repo, qv-notice-generate SKILL demoted to the documented fallback, and docs/devops/TIER-1-SCOPE.md §B1 created (the scope the ticket points at). A few things to confirm before this is considered done:

1. "Enforced" vs. warn-only. The ticket title says enforced in CI, but this ships in warn-only (shadow) mode — nothing blocks a merge yet. That matches the design doc's rollout sequencing, but it means this delivers the v0/shadow milestone, not literal enforcement. We should agree whether QVAC-21554 closes on shadow-mode or stays open until the blocking flip (which per the doc needs shadow-mode telemetry + TL sign-off).

2. Merge-order dependency + provisional pin. The caller is pinned to a qvac-actions feature-branch commit (0f4f710…, # pending 0.3.0). This must not be treated as complete until qvac-actions#12 merges, the 0.3.0 tag is cut, and this pin is repinned to the tag's immutable SHA. Flagged correctly in the PR — just calling out the ordering explicitly.

3. Manifest-only coverage. Since lockfiles are gitignored here, the gate classifies direct/manifest deps only, not the full transitive tree, so a disallowed transitive license can still pass the gate. Acknowledged in the SKILL doc and routed to the fallback — reasonable, but given DevOps Type = Security, worth making sure that limitation is visible to consumers, not only in the SKILL file.

No blockers, but points 1 and 2 gate whether this is "done" vs. "shadow-mode landed".

[GSServita]

Thanks @Proletter — responses below (code changes in 36b361d31, engine hardening in qvac-actions#12 ce61672c):

1. "Enforced" vs warn-only — closure semantics. Agreed this delivers the v0 / shadow-mode milestone, not literal blocking enforcement, matching the design doc's telemetry-gated rollout. Your call on how to track it — two clean options:

• (a) Close QVAC-21554 on shadow-mode landing and open a small follow-up ("promote license gate to required check on qvac") that owns the blocking flip once shadow-mode telemetry (false-positive rate, time-to-resolve) is acceptable and you've signed off; or
• (b) Keep QVAC-21554 open until the flip.
  I'd lean (a) so the shadow-mode work isn't left hanging, but I'll follow your preference before marking anything done.

2. Merge-order + provisional pin. Confirmed — not to be treated as complete until qvac-actions#12 merges, 0.3.0 is tagged, and this caller is repinned to the tag's immutable SHA. I've repinned to the current qvac-actions branch tip (ce61672c, still # pending 0.3.0) so this PR exercises the hardened engine; final repin-to-tag is the last step and this PR should not merge before it.

3. Manifest-only coverage visible to consumers. Done — surfaced beyond the SKILL doc: a coverage-limitation note in the caller header (.github/workflows/license-compliance.yml) and in docs/devops/TIER-1-SCOPE.md §B1, plus the prominent callout in the design doc (qvac-actions#12). The §B1 note also flags resolving it (commit lockfiles or schedule a SKILL audit) as a precondition for promoting the gate to blocking.