# Autonomous Web Operations Center ## Purpose Webdev Agent OS v7 extends the development lifecycle into production operations. It connects uptime evidence, incident response, release governance, analytics, experiments, Git status, and improvement campaigns to the persistent Project Command portfolio. The operating principle is: > Automate observation and recommendation. Gate production-changing decisions through accountable human approval. The system is not designed to make invisible production changes. Monitoring and evidence collection can run unattended. Deployments, experiments, campaign activation, destructive actions, and permanent business-rule changes require an explicit approval record. ## Operating loop 1. **Observe** — run HTTP monitors, collect status, response time, expected-content evidence, and business analytics. 2. **Detect** — open incidents after a configurable failure threshold and resolve them only after a recovery threshold. 3. **Diagnose** — correlate incidents, recent releases, quality history, Git state, analytics deterioration, and open approvals. 4. **Decide** — present approval requests to a responsible owner. 5. **Verify** — run the assigned production monitor after an approved deployment record enters the release pipeline. 6. **Measure** — compare conversion, revenue, availability, latency, and experiment outcomes. 7. **Improve** — create evidence-backed optimization opportunities and approval-gated campaigns. 8. **Learn** — preserve operational outcomes for Project Command and Web Intelligence. ## Core records ### Monitor A monitor belongs to a portfolio project and records: - URL and environment - GET or HEAD method - expected status range - optional expected response text - interval and timeout - incident failure threshold - recovery threshold - bounded check history - next scheduled run A minimum interval of five minutes is enforced by the core data model. The included scheduler is designed for ordinary availability checks, not high-frequency synthetic monitoring. ### Incident An incident opens only after a monitor reaches its failure threshold. It includes: - project and monitor linkage - severity - open, acknowledged, or resolved state - detection and resolution timestamps - failure count - timeline notes - accountable acknowledgment A successful check resolves an incident only after the configured recovery threshold is satisfied. ### Approval Approvals are first-class records for: - deployments - experiments - optimization campaigns The approval stores requestor, approvers, decision, decision owner, time, and notes. A rejected or cancelled request cannot silently proceed. ### Deployment The v7 deployment workflow is a controlled operational record and verification pipeline. It does not execute arbitrary shell commands or silently upload source code. A deployment records: - project, environment, version, branch, and commit - rollback reference - approval state - staged release status - assigned production monitor - post-release verification evidence The `run` action requires approval. It then runs the assigned enabled monitor and marks the deployment succeeded or failed from that evidence. Actual application deployment remains connected to the existing documented deployment process or an explicitly configured external pipeline. ### Analytics snapshot Analytics ingestion accepts consistent period snapshots: - visitors - sessions - conversions - calculated conversion rate - revenue - bounce rate - primary success event - source and notes The platform deliberately avoids claiming causality from a snapshot. It surfaces change and deterioration for investigation. ### Experiment Experiments require approval and record: - hypothesis - success metric - variants - visitors and conversions per variant - directional uplift - decision and interpretation The built-in comparison is directional. It does not claim statistical significance. The operator must verify tracking quality, sample allocation, duration, external effects, and statistical validity before permanent rollout. ### Optimization campaign A campaign coordinates a measurable improvement objective across one or more projects. Modes are: - `recommend-only` - `approval-gated` There is no unrestricted autonomous production mode. Campaign actions remain traceable and attributable. ## Optimization opportunity engine The engine currently creates prioritized recommendations for: - missing production monitoring - availability below 99% - P95 latency above two seconds - open incidents - missing analytics - conversion-rate decline - sufficient traffic without an active experiment - stale approval requests Each opportunity contains evidence and a recommended next action. It is a decision-support object, not permission to change production. ## Git integration Git integration is read-only. It uses local `git` commands to report: - repository root - current branch - latest commit and message - remote origin - clean or dirty working tree - changed file list It does not commit, push, merge, reset, or modify the repository. ## Control Center The Web Operations workspace provides: - portfolio availability, incidents, approvals, and conversion metrics - project-level scope filtering - live monitor checks - incident acknowledgment and resolution - approval decisions - deployment verification - conversion trend visualization - experiment evidence - optimization queue and campaign status - monitor, analytics, deployment, experiment, and campaign forms - Git status inspection - report and data export Static hosting displays the seeded example in read-only mode. Start the Node service for persistent actions. ## HTTP API ### Read - `GET /api/operations` - `GET /api/operations?projectId=` - `GET /api/operations/stats` - `GET /api/operations/export` - `GET /api/operations/git/:projectId` ### Monitor and incident actions - `POST /api/operations/monitors` - `POST /api/operations/monitors/:id/check` - `POST /api/operations/check-due` - `POST /api/operations/incidents/:id` ### Measurement and controlled change - `POST /api/operations/analytics` - `POST /api/operations/deployments` - `POST /api/operations/deployments/:id/run` - `POST /api/operations/experiments` - `POST /api/operations/experiments/:id/results` - `POST /api/operations/campaigns` - `POST /api/operations/approvals/:id/decision` - `POST /api/operations/report` ## CLI ```bash npm run operations:stats npm run operations:due npm run operations:check npm run operations:report node scripts/operations-cli.js view node scripts/operations-cli.js check node scripts/operations-cli.js approve approved "Responsible owner" node scripts/operations-cli.js git ``` ## Scheduling Run due monitors once: ```bash node scripts/operations-scheduler.js ``` Preview without network checks or writes: ```bash node scripts/operations-scheduler.js --dry-run ``` Windows helpers: - `run-web-operations.bat` - `run-web-operations.ps1` - `scripts/install-web-operations-schedule.ps1` No task is installed automatically. The optional installer creates a Windows Scheduled Task only when an operator explicitly runs it. ## Reports `POST /api/operations/report` or `npm run operations:report` produces: - `operations-report.html` - `operations-report.json` - `operations-report.md` Reports include executive metrics, monitor health, active incidents, pending approvals, recommended optimization actions, and deployment history. ## Data files - `config/operations-store.schema.json` - `config/operations-seed.json` - `config/operations-store.json` The seed data is illustrative. It contains labeled examples and should not be interpreted as verified live production evidence. ## Production limitations and next integrations The v7 engine is intentionally dependency-light and local-first. Enterprise production use should add: - authenticated API access and role-based authorization - encrypted secrets and credential management - independent external monitor locations - notification channels such as email, SMS, Slack, or incident systems - real analytics adapters - signed deployment-provider webhooks - protected environment approvals - immutable audit logging - retention and privacy policies - rate limiting - multi-tenant data isolation The included system is a strong operational control foundation, not a replacement for specialized global observability or regulated change-management platforms.