Track PDF derivation, signing, validation, and viewing lane for sourceos-shell rollout

[mdheller]

Summary

Track the PDF stack lane required for the sourceos-shell rollout, with explicit separation between Linux realization surfaces here and future product/runtime ownership in SourceOS-Linux/sourceos-shell.

Why this issue exists

The current Linux realization chain already carries shell/runtime scaffolds for:

• sourceos-pdf-secure
• sourceos-docd
• the shell service graph target

The contract layer also now includes the shell/document/publication family (ArtifactManifest, SignedArtifact, PdfValidationReport, AnnotationExport, RunReport, PublishDecision, MirrorReceipt, etc.).

What is still missing is a dedicated tracker that keeps the PDF lane coherent while the runtime repo is still absent.

Boundary

• SourceOS-Linux/sourceos-shell (future) = product/runtime ownership of the PDF pipeline and viewer
• SourceOS-Linux/sourceos-spec = typed contracts for PDF/document/publication objects
• SociOS-Linux/source-os = Linux realization surfaces and host/service wiring only

Workstreams

1. Derive lane

• Markdown -> PDF derivation path
• docd runtime ownership and host/service realization
• canonical artifact manifest production

2. Signing / validation lane

• pdf-secure ownership and Linux realization
• signing surface
• validation surface
• provenance ribbon inputs

3. Viewer / integration lane

• PDF viewing surface
• attachment to shell runtime once the runtime repo exists
• document-sidecar and report integration

4. Validation

• service graph checks for docd and pdf-secure
• artifact/report contract alignment
• follow-on executable tests once the runtime repo exists

Acceptance criteria

• PDF lane is explicitly tracked as its own workstream
• derive, sign/validate, viewer, and validation sub-lanes are distinguished
• follow-on PRs can reference this issue for PDF-specific work
• boundary with the future sourceos-shell runtime repo is explicit

Proposed owner

@mdheller