Changes and version control

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

Before this task: Record a local source baseline →

Choose the right versions, review the hardware impact, and make an explicit decision. SiliconForge combines local Git history with retained engineering snapshots; those are related, but not interchangeable.

Identify the versions first#

Open Changes for the connected project, or Review on a proposal. Read the baseline and target labels before interpreting any difference. The global Changes action opens working changes; an assistant handoff opens its particular candidate. A list of change rows belongs to one comparison, not a timeline of AI attempts.

• Git history records ordinary local commits, refs and parent relationships.
• Working comparisons distinguish current files, the Git index and a committed baseline.
• Checkpoints retain scoped engineering files and provenance in local SiliconForge state without creating a Git commit.
• Candidates are isolated proposed edits. Viewing one does not apply it or stage it in Git.

Choose a task#

• Stage and commit local changes: initialize Git, inspect the three layers, and commit exactly what is staged.
• Browse history and merge parents: inspect an existing ref without changing the checked-out branch.
• Save and compare checkpoints: retain engineering snapshots without inventing Git history.
• Review hardware differences: use architecture, RTL and retained source together.
• Review and apply candidates: separate execution approval, validation and application.
• Recover from stale or conflicted state: preserve newer work rather than retrying a stale write.
• Work with external Git tools: branches, remotes, signing, hooks and backups.

Read the comparison#

Gray / shared

No detected structural change in the displayed comparison.

Amber / Δ

A matched object has a detected modification.

Red / before-only

Original structure without a matched after counterpart.

Green / after-only

Replacement structure without a matched before counterpart.

Question mark

Matching is uncertain; it is not proof that functionality was added or removed.

Overlay shows both alternatives, not a circuit with both installed. Green does not mean correct, red does not mean faulty, and unchanged architecture does not establish unchanged behavior. Inspect RTL, source and verification evidence as well.

Apply or reject#

1. Confirm that the comparison and validation refer to the exact candidate under review.
2. Inspect failed, missing and unsupported checks as well as passes. Review notes record observations; they do not grant approval.
3. Use the proposal's explicit Apply action only when the candidate is validated and still based on the current project. Reject leaves canonical files unchanged.
4. After applying, inspect the resulting files and relevant verification. Commit separately if you want a Git revision.

If the project or index changed, refresh and resolve the mismatch. Do not overwrite later edits to make an old candidate apply. Project recovery and application-installation rollback are different operations.

Know the current boundary#

The native Git workflow covers initialization, whole-file stage/unstage, local commits and read-only history/ref browsing. It is not a replacement UI for every Git command: checkout, merge, rebase, fetch, pull, push and signing remain external-tool tasks. Hardware review is a scoped engineering interpretation, not a formal equivalence proof or a full-directory backup.

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