Skip to main content

Run practice reviews

Hephaestus checks eligible work against workspace practices and records observations before preparing feedback. A failed capture creates no observation. A quiet review can have observations without delivered feedback. The vocabulary owns outcome and feedback terms.

First successful review​

  1. Open the workspace's practice settings.
  2. Assign a review model within members' AI choices.
  3. Select the repositories and people in review scope.
  4. Check that the practices use Hephaestus under Reviewed by.
  5. Set Feedback mode to Approve first while you inspect the first review.
  6. Request a review of eligible work.

A request follows scope, consent, source-access and budget checks. The record that you asked from keeps its status. About must resolve to exactly one eligible human account unless the definition explicitly concerns no developer. Missing or ambiguous roles withhold the practice without inventing attribution.

Check that it worked​

  1. Select the link to the new review that the accepted request shows.
  2. Inspect Observations and Problems.
  3. Read capture and withholding reasons before you interpret a quiet review.

Approve eligible feedback only after you check the complete proposed text, as Approve, reject and retry describes.

Follow one review end to end​

Read the recorded event or request, source readiness, observation and feedback state separately. A capture failure is not Could not determine. A refused candidate observation is Withheld, with no observation row. A delivered comment does not prove that the observation was correct.

Practice scripts shows each script's execution state, model use and stop reason. Execution details can expire while observations and delivery history remain available. The operations guide owns deployment controls. Data retention owns the retention periods.

Feedback mode, review scope and delivery​

Reviewed by controls whether a practice has automated review. Hephaestus permits it. People requires human review. Nobody keeps guidance without automated review. Feedback mode controls delivery independently:

ModeBehavior
OffReviews can record observations. No feedback reaches any destination.
Approve firstEligible feedback on the work waits for admin approval. Private destinations keep their own checks.
AutomaticEligible feedback on the work can proceed after all normal checks.

Feedback on the work also depends on the state of the work when it is sent:

  • Draft: no feedback on the work. The practice page and the conversation can still get theirs. Marking the work ready starts a review of each practice that reviews on Ready, and that review can comment.
  • Merged or closed: no feedback on the work, unless Post feedback after merge is on. It is off by default. The practice page and the conversation can still get theirs. With the setting on, feedback on the work still follows each practice's own state conditions.

Withheld feedback appears under The work moved on, with a sentence that says why. GitHub Copilot code review, CodeRabbit and GitLab Duo Code Review also wait until a draft is ready by default.

A practice can inherit from its group and workspace. Reset an override to inherit again. A settings change never approves an old proposal implicitly.

Review scope selects repositories and accounts, not provider login strings. Widening scope requires the normal preview and confirmation. Delivery pause stops external feedback while reviews can continue. Pause and resume it in Review settings → Feedback mode → Sending feedback. The account's Comments and Slack reminders preference remains a separate external-delivery check. AI choice, source consent and instance silent mode are also separate constraints.

Approve, reject and retry​

Inspect every summary, line note and supporting observation in a proposal. Approval binds the exact text, anchors and developer. Approve and reject can change only before a copy write begins or a send is claimed. A later policy change cannot make an unsafe reversal valid.

Unknown visibility shows Unconfirmed. A started write can already exist at the provider. Automatic recovery performs readback without repeating the write.

Use Check delivery to ask the provider again whether an unconfirmed comment appeared on the work. The check posts nothing. You can also check withdrawn feedback. If the check finds the comment, Hephaestus retracts it.

While the visibility of a comment is unknown, later reviews post no new feedback for that developer on that work. An approval that is refused for this reason leaves the feedback in approval. First use Check delivery on the feedback marked Delivery unconfirmed for that developer and work. An explicit retry is permitted only after proved absence and current approval, consent and source checks. A confirmed copy is never posted again.

A parent can stay Unconfirmed while another copy has a confirmed delivery time. Read copy details rather than treating the entire package as absent. The overview counts such feedback in its own Partly delivered row, and the row opens the feedback list filtered to it. The Delivered total counts only complete delivery. A failed part also counts toward delivery failures.

After a retry, the feedback reads Unconfirmed while the retried copy is pending or its appearance is uncertain. If the retry fails, the feedback reads Failed.

Correct observations and feedback​

Mark incorrect when the observation was wrong when made. Give a reason. The observation stays in history without supporting new feedback.

The system withdraws only the copies that rest on the observation. Other copies of the same feedback stay posted. It requests supported provider correction after reconciling any started write. An unsupported correction retains the actual posted copy and its reason.

Remove the mark to reverse it. The system writes the original words back into the same provider notes and posts nothing again. A copy stays withdrawn until the last mark on its support is gone.

Mark accepted to remove an observation from open-problem lists and current open report counts. Give a reason. The recorded outcome and total problem count do not change. Acceptance is not proof that the developer repaired the work.

It does not cancel an incorrect mark. Remove either mark with a reason to reverse it. Neither action revives an older claim or changes the observation's end time.

Withdraw a private card when correct observations led to incorrect words. Restore reverses withdrawal if current checks permit it. Withdrawal does not change observations or erase a confirmed first-read time. A developer's disagreement is a response, not an automatic admin mark.

Read unavailable evidence​

Source permissions can make summaries, explanations, examples and quotations unavailable. Safe outcomes, identifiers and delivery facts can remain visible. Unavailable detail does not mean the observation has no problems. Private card and conversation text remains private on operator observation views. A rating alone does not expose the developer's note to admins.

Scans and reports​

Scan a repository describes default-branch scans and SARIF exports. A scan has no developer feedback or personal standing. It records file observations, Withheld pairs and Not reviewed pairs separately. Use recorded counts for the close-time summary and open counts for current eligible problems.