Skip to content

Publish reusable continuity handoff preflight and PR validation workflow #60

Description

@szmyty

Outcome

Publish a reusable continuity handoff preflight that coding agents invoke before presenting a pull request, plus a read-only pull-request validation workflow that provides the same deterministic backstop in CI.

Dependencies and ownership

Relay executes and publishes reusable automation. It must not own continuity semantics or generate unreviewed semantic prose.

Two execution points

1. Local/pre-PR preflight

Expose a stable command/task adapter that Aether skills, Copilot, Codex, and local hooks can run after project validation and immediately before a pull request is opened or updated.

The preflight should:

  • identify the explicit base and candidate revisions;
  • invoke the pinned EgoLint continuity capability;
  • confirm that CONTINUITY.md and the managed AGENTS.md pointer satisfy the active profile;
  • confirm the handoff update or policy-valid exemption is represented in the candidate diff;
  • emit actionable human and machine-readable results;
  • never stage, commit, push, open a pull request, or rewrite semantic content on its own.

2. Pull-request CI backstop

Publish a reusable workflow/action that runs on safe pull_request events and:

  • checks out the exact base/head evidence with the documented history depth;
  • runs the same pinned validation used locally;
  • supports observe, ratchet, and enforce modes;
  • adds concise annotations and a durable report artifact;
  • distinguishes missing update, invalid file, unverifiable mutable state, and valid exemption;
  • uses least permissions and executes no untrusted code with privileged credentials;
  • never mutates the branch or comments unless a separately reviewed contract authorizes that adapter.

CI happens after the pull request exists, so documentation must describe it as a backstop rather than the mechanism that performs the requested pre-PR semantic update.

Change classification

Consume the Hygiene policy for which changes require a refreshed checkpoint and which narrowly defined changes may use a no-change/exemption record. Do not hard-code repository-type guesses in Relay.

At minimum test source, architecture, roadmap, dependency, generated-output, documentation-only, automated dependency, and metadata-only changes. A file timestamp or touched bit alone is not proof of semantic freshness.

Security and failure behavior

  • Pin all reusable actions and validation artifacts immutably.
  • Use pull_request, not privileged execution of untrusted fork code.
  • Do not expose repository contents from private consumers in public artifacts or logs.
  • Fail clearly for missing base refs, shallow history, unsupported contract versions, and unavailable validators.
  • Make cancellation, concurrency, retry, timeout, and artifact-retention behavior explicit.
  • Keep local and CI result schemas byte-compatible where practical.

Acceptance criteria

  • One stable local/pre-PR entry point and one reusable PR validation workflow exist.
  • Both consume the same released EgoLint capability and pinned contract versions.
  • The local preflight performs no implicit Git or GitHub writes.
  • CI is read-only, least-privilege, fork-safe, and clearly documented as a backstop.
  • Observe, ratchet, enforce, exemption, unsupported, and unavailable states are tested.
  • Base/head behavior is verified for merge commits, squash merges, rebases, shallow clones, and parallel PRs.
  • Human annotations and machine-readable evidence identify exact corrective actions.
  • Private repository fixtures prove logs and artifacts do not leak checkpoint content unnecessarily.
  • A consumer can call the preflight through its canonical Taskfile/local-hook interface without duplicating validation logic.
  • No workflow authors, commits, pushes, opens, merges, deploys, or publishes work.

Non-goals

  • Asking CI to write the continuity summary.
  • Treating a changed CONTINUITY.md as semantic proof by itself.
  • Creating a second continuity schema.
  • Requiring GitHub Actions for local-only consumers.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions