Review and apply candidates

Applies to SiliconForge 0.1.2 · Updated 2026-09-30. Check platform limits.

Before this task: Approve a bounded plan and shared context →

Review an isolated proposal, validate its exact contents, and explicitly choose whether it may change the trusted project.

Start with a connected, saved project#

Save editor changes and identify the intended top, files and verification setup. For an AI request, inspect the plan and context before choosing Approve & Execute. That approval starts execution in an isolated workspace; it is not permission to apply every result to canonical project files.

A candidate retains proposed contents and their hashes against a particular base. “Frozen” means the decision must refer to those exact contents, not whatever happens to be in a directory later. Editing the base or candidate after review can invalidate the decision and validation.

Worked flow: review a proposed RTL fix#

1. Request one bounded fix, such as correcting a counter's enable polarity. Inspect the plan and affected scope, then use Approve & Execute when appropriate.
2. When the candidate is ready, choose Review. Confirm the baseline, target and affected files; use hardware and source review to inspect the actual change.
3. Choose Validate on the proposal. Read the actual tool results and their bindings. An unavailable tool, unsupported check or old result is not a pass for this candidate.
4. Use Explain to inspect warnings and uncertainty. If further changes are needed, request a bounded repair through the proposal workflow and review the resulting candidate again; do not carry a previous pass forward unquestioningly.
5. If the exact validated result is acceptable and still based on the current project, choose Apply. This is the explicit approval-and-application boundary.
6. Inspect the resulting canonical files and relevant post-apply verification. Stage and commit separately through the Git workflow if the result should become a Git revision.

For an unapplied candidate that you do not want, use Reject. Rejection records the disposition and removes its candidate workspace without replacing canonical files. An already applied proposal requires a recovery operation, not rejection. Do not reject active execution as a substitute for using its supported interruption workflow.

Select files without confusing Git staging#

In a local proposal comparison, select the retained source file and choose Stage file…. This creates a new unapproved candidate containing the selected file. It does not stage that file in the Git index, approve it, or directly apply it to the working project.

Validate and review the resulting project as a whole. A one-file selection does not prove dependency independence: an RTL change may require another module, testbench, manifest or constraint edit. If the original candidate's base no longer matches the trusted project, selection is refused; reconcile the project and prepare a fresh candidate.

Imported comparisons and ordinary historical comparisons do not acquire local write authority simply by opening them. Their inspection controls are useful, but candidate actions require a locally bound proposal.

Prepare a reviewed reversion#

For an applied local proposal, Revert candidate… creates a new candidate that reverses that proposal using its retained rollback evidence. It does not immediately replace project files. Review and validate the reversal, then explicitly apply it if suitable.

Reversion checks for conflicts with later changes. A non-conflicting later edit may be preserved; an overlapping edit or changed/recreated path can block preparation. Treat that refusal as a conflict to resolve, not permission to remove the newer work.

The proposal's Rollback action is a different, guarded restoration operation for an applied proposal. It also refuses unsafe or changed rollback inputs. Back up first and consult candidate recovery. Neither operation is the application installer's version rollback.

When validation or apply is blocked#

• Base changed: compare current files with the reviewed baseline and prepare a new candidate against current work.
• Candidate content changed: do not edit private candidate files to defeat hash checks; regenerate and revalidate through the workflow.
• Missing or mismatched validation: run the required real checks for the exact candidate, with the necessary tools and configuration.
• Missing rollback evidence: preserve project state and recover from a verified backup or reviewed manual change; do not fabricate evidence.

Notes, checkmarks, a readable diagram and successful Git staging are not candidate approval or verification.

Need help? Report an issue. Include your application version; never include credentials.