Start from a verified installation
A customer update needs the existing Founder Repo OS installation evidence: a verified project profile, installation receipt, repository binding, and managed-file metadata. The review uses that profile to prepare a supported package update for the same repository. It does not rebuild unknown project choices from a generic template.
If the profile or receipt cannot be verified, or the installed version has no supported update path, stop and resolve that prerequisite. A newer package being available is not enough to justify writing files into an existing project.
Example conflict
You changed the instructions. The package changed them too.
Suppose you customized AGENTS.md with your team's check commands after setup. A later product version also changes that managed file. The update review compares the source package, the current repository content, and the proposed target. If both sides changed the file differently, it identifies a conflict and blocks the update from creating a branch until the conflict is resolved.
A customer change can instead be preserved when the target package did not change that file. An unchanged managed file that the target package no longer includes is shown as a removal candidate and preserved by the current update path. A customized removed file can instead need conflict review. Read the proposed action for each file; do not infer it from the update version alone.
Turn the review result into the next action
A file status describes the proposal, not proof that the update is already installed.
SAFE_UPDATE/SAFE_ADD- Inspect the proposed content. These are write candidates, not proof that your application tests passed.
CUSTOMER_MODIFIED- Your current state is preserved when the target package did not change that file. Check that your custom instructions still fit.
REMOVE_CANDIDATE- The unchanged file is absent from the target package but preserved by the current update path. This is not an automatic deletion.
CONFLICT- Pause for a human decision. The blocked review cannot create an update branch. After changing repository files, run a fresh review.
If the repository's default branch changes after approval, run a fresh review. A draft PR does not mean the new version is installed: recording that version requires your merge and a subsequent verified default-branch readback.
Before approving an update
- Confirm the source. Check the bound repository and the installed and target product versions.
- Read the complete managed-file diff. Inspect additions, changes, preserved custom work, and removal candidates.
- Resolve blockers. A conflict needs a decision; a blocked review cannot create an update branch.
- Approve current evidence. If the repository changed after review, generate a fresh review.
- Review the draft PR. Run the applicable repository checks and decide about the merge yourself.
A controlled update proposal, with your merge decision
Founder Repo OS, a product by SUPPE LABS, checks the current repository again before applying an approved update plan. A ready plan creates a dedicated update branch and draft pull request. It does not write directly to the default branch, merge automatically, or deploy the project. Review and merge remain customer decisions.
This path updates the supported Founder Repo OS foundation and its managed files. It does not update every application dependency, resolve every conflict, or supervise changes made by other AI tools. Keep your application tests, repository protections, and release process in place. For an initial installation, the separate six-step guided setup includes repository scan, configuration, and full-diff review before an approved setup branch and draft PR.