27 lines
1.3 KiB
Markdown
27 lines
1.3 KiB
Markdown
# Mutation and reconciliation model
|
|
|
|
ForgeFlow separates observation from state changes at the API boundary.
|
|
|
|
## Discovery
|
|
|
|
`scanServerInventory()` and `discoverServerWorkloads()` collect Docker, Compose, DockerMan and Git evidence. They may write diagnostic logs, but they do not save, update or delete deployment profiles and do not change containers.
|
|
|
|
## Reconciliation planning
|
|
|
|
`planServerInventoryReconciliation()` returns a content-addressed plan containing:
|
|
|
|
- exact links that may be added;
|
|
- existing profiles whose observed metadata may be refreshed;
|
|
- stale profiles that require review;
|
|
- ambiguous workloads that block automatic application.
|
|
|
|
The plan identifier changes whenever its proposed scope changes.
|
|
|
|
## Reconciliation application
|
|
|
|
`reconcileServerInventory()` requires the exact reviewed plan identifier. It rescans the server and refuses a stale plan. Before writing configuration it creates a private recovery snapshot. Stale profiles are reported but never removed automatically.
|
|
|
|
## Direct mutations
|
|
|
|
Manual linking, unlinking, deploy-key rotation, deployment and rollback remain separate explicit commands. Each must append an audit event with repository, profile, operation identifier and result. Destructive commands need a dedicated confirmation flow and recovery path.
|