System updates

atualizacoes-sistema.php supports CLI execution and a web flow. Full mode downloads or uses a local artifact, verifies SHA-256 when a checksum file is available, extracts into staging, and validates critical files. It first replaces its own updater script and runs the new version; it then applies files and updates the database. The web flow has start, deploy, db, and finalize stages linked by a session ID.

The contents/, logs/, backups/, temp/, and autenticacoes/ directories are protected from file overwrite. --dry-run simulates changes, --backup makes a backup before applying them, and --only-files and --only-db run separate stages; the latter two cannot be combined. The database updater follows schema-metadata.json rules, including preservation of user-modified fields. See resources.

Before moving staging, core migrations the artifact no longer ships are removed from db/migrations (req-194, atualizacoes-migracoes.php). The folder has two owners — core and project —, each with its own manifest (db/.c2f-migrations-core.json, db/.c2f-migrations-projeto.json); a core update never deletes a project migration and logs version or class clashes.

After the database step, db/ stays in place, in both CLI and web (req-197): the folder holds both owners' migrations and the manifests above.

Deploy lock (req-197). Every update except --dry-run runs under the environment lock at temp/deploy.lock, the same one used by the API project deploy. While another deploy is running, the CLI refuses with exit code 8 and the web start refuses with locked; the message says who holds the lock. An expired lock (a process that died) is taken over, with a warning in the log. In the CLI, the bootstrap process takes the lock and passes the token to the child (--lock-token), which adopts it. On the web, start takes it and finalize/cancel release it. --backup copies the whole installation to backups/atualizacoes/full/<date>/, without the protected folders, before touching any file.

Layers and clashes (req-198). Every delivery records what it delivered in installation/manifests/<layer>.json (path and sha256), and precedence is projeto > plugin:<id> > core. Before moving staging, a core update:

• does not overwrite a file the project or a plugin overrides: the new version goes to backups/overrides/<version>/ and becomes an sobreposto clash;

• keeps a file changed on the server when no layer delivered that content (editado clash);

• removes what the core stopped delivering when it is intact; when it was edited, it becomes a retirado-editado clash.

The first delivery, without a manifest, behaves as before and records the baseline. Clashes are stored in installation/choques/ and, after the database stage, in the atualizacoes_choques table (the same clash still pending does not become another row on every update); the "Delivery clashes" section of admin-atualizacoes lists them with the diff, and the detail page holds the per-file decision: overwrite, keep or merge (req-199; also through the API and c2f update:conflicts / update:resolve). "Keep" becomes a rule for later deliveries of the same file, and a layer delivering the same content as before creates no clash. installation/ is a protected folder.

Data that leaves (req-199 / BATCH-207). The database sync also removes what the owner stopped delivering:

• every delivery records, per owner (core or the project id), the natural key of each delivered record in installation/manifests/recursos-<owner>.json;

• on the next delivery, what left the same owner's list leaves the database: status='D' when the table has status, otherwise the record is deleted;

• a record edited online (user_modified=1) does not leave: it becomes a record clash (db:<table>?<key>), and "overwrite" accepts the removal;

• only natural-key tables take part (pages, layouts, components, variables, templates…). The core only removes records without project, and a project only its own. What was created in the panel never entered a list, so it never leaves;

• what the removal marked comes back on its own: the manifest keeps, under retirados, each marked key and the status the record had. When the same owner delivers the key again, the record returns to that status. Only what this routine removed comes back; a record disabled some other way never enters the list;

• an owner's first delivery to a table only records the list. --dry-run only simulates; --no-resource-removal (in atualizacoes-banco-de-dados.php) turns it off. The imperative deletar list in schema-metadata.json still covers one-off cases.

File recovery (req-200). /_api/project/files compares disk contents with the manifests and downloads differences. c2f project:recover-files uses the same three-action clash engine when a project file also changed in the local repository. The downloaded copy is the new version and decisions are recorded in temp/recover-files/.../relatorio.json. Core and plugin files are available for inspection without being applied to the local project.

Snapshot, check and rollback (req-198). Before applying, the update keeps in backups/atualizacoes/snapshots/exec-<id>/:

• only the files that will be overwritten or removed, the list of new ones and the manifests;

• a database dump (banco.sql.gz, via mysqldump), before the database stage.

Afterwards it checks for a new fatal error in logs/php-error.log and that the site root answers below 500:

• the request goes to https://<domain>/, through normal DNS and, when it cannot connect, through 127.0.0.1;

• --health-url=<url> and --health-ip=<ip> (or ATUALIZACOES_SAUDE_URL and ATUALIZACOES_SAUDE_IP in .env) point to another address, for example an nginx on an internal port;

• when no attempt connects, the HTTP check becomes a warning and does not fail (the server may listen only on its public IP);

• it waits 3 s before the request, because the PHP-FPM OPcache still serves the old code for a few seconds. When the check fails, files are restored automatically (exit code 6). The database is restored only by operator decision: --rollback=exec-<id> --com-banco. --rollback=exec-<id> alone restores only the files; --no-health and --no-rollback turn off the check or the automatic restore. The 5 most recent snapshots are kept. The API project deploy does the same (api-… snapshots), and rollback can also be triggered from the development machine with c2f update:rollback or POST /_api/project/rollback (BATCH-204). The full update can also be triggered through the API, in the background, with the same options and followed with run-status (system API, req-201).