Phase 7 Launch Readiness

Product Scope

Limier is for one narrow review job: compare a baseline and candidate dependency version inside a controlled fixture, capture the behavior each version triggers, and tell a reviewer whether the change looks safe enough to approve, needs review, should be blocked, or should be rerun.

Limier is not a general application security scanner. It does not promise to detect SQLi, XSS, CSRF, authentication bugs, or broad secure-coding flaws in the fixture application.

When telemetry.mode is required, the current implementation requires Linux, cgroup v2, eBPF support, and bpftrace. If capture cannot complete, Limier fails closed with an inconclusive rerun diagnostic instead of silently dropping process coverage. Output-only mode always requires human review.

Repository-Owned Validation Corpus

The Phase 7 validation corpus lives under validation/corpus/ and is enforced by go test ./....

Current cases:

• good-to-go-no-diff.yml: routine benign upgrade with no typed diff, expected good_to_go
• good-to-go-suppressed-benign-noise.yml: benign stdout drift suppressed by a sample-specific ruleset, expected good_to_go
• needs-review-new-helper-process.yml: candidate introduces a new helper process, expected needs_review
• block-network-fetch-during-install.yml: candidate introduces a new curl fetch during install, expected block
• rerun-unstable-candidate.yml: candidate behavior is unstable across repeats, expected rerun

Reviewer Journeys

• Platform engineer: run the sample workflow and confirm a routine upgrade stays good_to_go.
• Security engineer: inspect a report where a candidate introduces a new helper process and confirm the report surfaces the changed step, phase, and evidence path.
• Security or platform reviewer: inspect a blocked install-time network fetch and confirm the default rules make the hard-block reason explicit.
• CI operator: inspect an inconclusive report and use summary.md, report.json, and limier inspect to understand why the run should be rerun.
• Platform or security engineer: wire Limier into Dependabot pull requests and confirm that telemetry.mode: required fails closed when kernel telemetry is unavailable, while telemetry.mode: off produces an output-only result that requires human review.

Launch Checklist

• Docker lifecycle commands now capture bounded output instead of buffering unbounded create, start, and remove output in memory.
• CI examples point at real repository assets and use Go 1.26-compatible provisioning.
• The repository ships real fixtures/, scenarios/, and rules/ directories.
• The validation corpus covers good_to_go, needs_review, block, and rerun.
• Default rules are shaped around suspicious dependency behavior, especially new process execution and install-time drift.
• Summary, render, and inspect outputs expose repeat stability and whether a finding happened during install or execution.
• Documentation states the narrow product scope directly and links to a runnable sample workflow.
• Documentation distinguishes the repository-owned sample CI workflow from a real Dependabot-triggered pull-request integration.
• GitHub Actions guidance makes required kernel telemetry versus output-only review semantics explicit.