# GLMChat V2.2 Administration and Operations Guide

Updated: 22 July 2026

## 1. Feature-locked architecture

- React PWA frontend using local vendored runtime assets.
- PHP 8.2+ backend.
- SQLite server persistence.
- IndexedDB client persistence and ordered offline mutation queues.
- LiteSpeed or Apache-compatible shared hosting.
- No production Node.js, Python, Composer, WebSocket daemon or alternate database.

## 2. Storage and permissions

`storage/` must be writable by PHP and denied to web requests. It contains server state, databases, logs and project data. Do not make it world-writable when a more restrictive hosting-specific ownership or ACL arrangement is available.

Preserve `storage/.htaccess`. Confirm directory listing is disabled and direct access to database, log, key and backup extensions is rejected.

## 3. Database operations

- SQLite uses foreign keys, busy timeout and WAL where available.
- Migrations are checksummed and forward-only.
- Take a complete storage backup before every application upgrade.
- Do not replace the production database with the empty packaged storage directory.
- Do not edit migration files after deployment.
- Investigate a checksum mismatch rather than bypassing it.

## 4. Security operations

- Keep the site HTTPS-only.
- Configure trusted proxy TLS only through the server environment, never a client-controlled header.
- Preserve the restrictive CSP and no-store API headers.
- Do not expose `source/`, `tests/`, `scripts/`, `handover/`, `evidence/`, `implementation-prompts/`, `server/` or `storage/`.
- Rotate the Together API key if credential exposure is suspected.
- Review rate-limit, lockout and recent-PIN behaviour after host or session configuration changes.
- Keep diagnostics disabled unless required, and export only secret-safe diagnostic records.

## 5. Tool administration

The PHP server is authoritative for the tool allowlist. A UI entry alone does not grant execution.

For each tool, review:

- stable identifier and JSON schema;
- read-only, mutating or destructive risk class;
- project path confinement;
- timeout and output limits;
- approval and recent-PIN policy;
- idempotency and retry rules;
- redaction of logs and returned errors.

Never add arbitrary shell execution, unrestricted filesystem access or dynamically supplied PHP code.

## 6. Cost governance

Configure daily and workflow-level limits before enabling wider use. Verify provider pricing assumptions in the current environment. The server, not only the interface, must enforce hard limits. Review cost events by project, run, worker and model when investigating unexpected use.

## 7. Service-worker and cache operations

- Publish fingerprinted immutable assets first.
- Publish mutable metadata and `sw.js` next.
- Publish `index.html` last.
- Never reuse a fingerprinted URL for changed bytes.
- Keep API, setup and authentication responses out of Cache Storage.
- Clear only obsolete GLMChat shell caches during recovery.
- Do not clear IndexedDB or pending queues as part of a normal update.

## 8. Routine maintenance

- Review application health and controlled bootstrap status.
- Check available disk space and SQLite growth.
- Review logs for repeated authentication failures, retry exhaustion or tool rejection without retaining secrets.
- Test backups by restoring into a non-production environment.
- Verify PWA update behaviour after every release.
- Re-run the live acceptance checklist after PHP, LiteSpeed, TLS, proxy or directory-permission changes.

## 9. Incident response

1. Preserve logs and storage safely without publishing them.
2. Record the release hash and environment details.
3. Revoke or rotate exposed provider credentials.
4. Disable destructive tools if tool execution is implicated.
5. Preserve queued mutations before clearing any browser data.
6. Use the stable user-facing error code and sanitised diagnostics for investigation.
7. Restore application files as a coherent release; do not mix immutable assets between releases.

## 10. Release verification

A production release is acceptable only when:

- source and deployment archives pass clean extraction;
- manifests and asset fingerprints match;
- PHP and JavaScript syntax checks pass;
- feature-lock contracts pass;
- migration scenarios pass;
- PWA/offline/accessibility suites pass;
- no high-confidence secrets are present;
- live host, physical Android and live Together checks are recorded truthfully.