Seyal is open source under AGPL-3.0 when the source is published. Read the self-host guide
seyal
Menu

The life of a task, from request to proof.

Six steps. The last one runs only when the work before it is proven, and every step leaves an event behind.

Six glass steps lead through evidence and approval to a completion seal.
  1. 01

    Capture and place the request

    Start in the web app, send a request through MCP or connect a Microsoft 365 intake mailbox. Triage incoming requests into the right project. Intake also sets the task's risk and areas, which decide who reviews it.

    Write the acceptance criteria

    The project Definition of Done is copied into new tasks. Add the specific outcomes this task needs to satisfy.

  2. 02

    Claim the task

    A person or coding client takes a claim before working. One live claim helps the team see who owns the next action.

    Keep progress visible

    An agent reports with log_progress. Reports renew its claim; after five minutes without a report the claim becomes stale. An agent can also post its plan with post_plan and report each step with report_step, so the task shows the run as it happens.

  3. 03

    Open a PR and attach evidence

    The coding agent does the work in your repository, opens a pull request and links it to the task with link_pr. With a connected GitHub or Azure DevOps repository, commits that name the task key log progress and opening the PR moves the task to In review.

    Keep review and verification distinct

    People review and merge PRs. A merged PR moves the task to Verify; it does not mark it Done. Required evidence still has to be present in the expected state.

  4. 04

    Check the criteria

    Review the result against every acceptance criterion and tick the ones that are met. A task with no criteria, or an unticked criterion, cannot pass completion.

    Check the required evidence too

    The completion check tests each evidence kind required by the task. An open PR alone does not satisfy a requirement for a merged PR. When a task requires review, each picked reviewer's newest verdict on the current version must approve.

  5. 05

    Approve that exact version

    A person reviews and approves a proposal tied to the current task version. Approval of an older version cannot unlock the current task. A pull request that touches protected files, such as CI definitions or agent control files, needs a person with the owner role and checks Seyal can trust.

    Keep the reviewer in the loop

    A request through complete_task can ask the owner for approval when that is the only missing requirement. It never supplies approval on the person’s behalf.

  6. 06

    Pass the check to reach Done

    The task service checks the criteria, required evidence and approval together. A refusal lists the gaps so the next action is clear.

    The same gate from every route

    Web actions and MCP tools use the same completion check. Project policy also controls whether an agent may request completion.

Changed work needs fresh approval

Approval stays tied to what was reviewed. Editing the task increments its version and makes an earlier approval stale.

The trail stays with the task

An illustrative history, using fictional names and task records.

APP-12 · example event history

  1. Codex claimed the taskv7
  2. Completion check refused: requirements missingv7
  3. Codex attached PR #48 and checksv7
  4. Sam Lee approved this versionv7
  5. Completion check passed · Donev7
  6. Sam Lee changed the task · approval stalev8