What task are you trying to do?

Make PawWork CI a trustworthy PR quality gate, so pull requests into dev are checked not only for type correctness and unit-level regressions, but also for basic product validity along the paths that matter to users.

What do you do today?

Today CI is split across four workflows, but the overall gate is still narrower than the product risk surface. ci.yml mainly runs typecheck and unit tests. desktop-smoke.yml proves the Electron app can build and package, but not that a minimal user path still works. e2e-artifacts.yml is intentionally non-blocking diagnostics on Linux, so it helps investigation but does not stop a bad PR from merging. We also identified workflow-level hardening work in #24 and #37, but keeping CI improvement split across multiple issues makes it harder to reason about what CI is supposed to guarantee overall.

What would a good result look like?

• CI has a clear contract: it should provide credible evidence for PR code quality and basic product validity, not only compile-time correctness.
• Workflow foundation hardening is in place across CI workflows: third-party action pinning where appropriate, explicit persist-credentials: false where checkout does not need to push, and Dependabot coverage for GitHub Actions updates.
• Non-blocking E2E diagnostics are easier to trust and review: failure visibility is obvious in PRs, the workflow contract test is structure-based instead of brittle text matching, and path-leak guards are general rather than user-specific.
• At least one blocking product smoke check exists for the PR path that matters most, so CI can catch "build succeeds but product flow is broken" regressions before merge.
• Lightweight quality checks are added only where they produce high signal, for example a low-noise lint or code-quality gate, without turning CI into a noisy style-enforcement system.
• The implementation can still land as several small PRs, but they all track back to one CI improvement issue instead of fragmenting across separate enhancement threads.

Which audience does this matter to most?

Both

Extra context

• This issue supersedes #24 and #37 as the single planning thread for CI improvement.
• Current workflows in scope: .github/workflows/{ci,desktop-smoke,e2e-artifacts,build}.yml.
• The most important shift is from "CI hardening as isolated workflow cleanup" to "CI as a trustworthy PR gate".
• Likely workstreams:
  • CI foundation hardening, including the security baseline from #37
  • E2E diagnostics hardening, including the follow-up items from #24
  • Blocking product smoke checks for a minimal real user path
  • Lightweight code-quality checks if they add signal without high noise
• Non-goals for the first pass:
  • full end-to-end coverage for every workflow
  • heavy coverage thresholds
  • broad style-only lint churn
  • redesigning release CI beyond what is needed for PR trustworthiness