Skip to main content

Practice review

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.
  7. Open Practice reviews and inspect Observations and Problems.
  8. Read capture and withholding reasons before interpreting a quiet review.
  9. Approve eligible feedback only after checking the complete proposed text.

A request follows scope, consent, source-access and budget checks. An accepted request shows a link to the new review. 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.

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.

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. 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.

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 requests supported provider correction after reconciling any started write. An unsupported correction retains the actual posted copy and its reason.

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.