CISRE (William-Lu-stack/Flawless): a Kubernetes SRE agent that refuses to call a 2xx a recovery

The failure mode CISRE was built to remove

Most AI operations tooling stops at a diagnosis. The model reads telemetry, names a probable cause, and hands a paragraph of text to whoever is on call. CISRE's README states the gap it targets in one line: an execution API returning success, a model claiming success, or an old instance still being healthy are all insufficient evidence that the incident is over. The platform is aimed at SRE and platform teams who already accept automation for detection and diagnosis but who will not let a language model touch a production cluster without a gate. The repository describes the audience indirectly through its delivery model: domain teams ship a plugin folder with a manifest, a read-only provider, skills, a typed action catalog and contract tests. That is an internal platform team's workflow, not a solo operator's. The product name in the README is CISRE (Cloud Infrastructure Site Reliability Engine); Flawless is the repository name, and version 5.6.0 is the current release line.

Discovery to verification: the ten-stage chain and where the model is allowed to act

The documented flow is a pipeline, not a chat loop: discovery, forensics, diagnosis, skill routing, change preview, human approval, execution, same-target readback, stability verification, then records and skill effectiveness. A branch runs underneath it, so a target that has not recovered keeps its evidence and switches strategy rather than closing the ticket. The architecture separates responsibilities by role. The model interprets, plans and explains. Skills hold domain handling knowledge. Plugins supply composable capabilities. The Harness owns state, permissions and orchestration. A controlled executor performs the actual change, and a Verifier proves the target recovered. Any real mutation, per the README, must pass through a fixed sequence: typed action, then policy and blast radius, then human approval, then executor, then same-target readback, then recovery verifier, then record. The reason this matters is that the model is never the executor. Agents live in agents/ and, as the architecture section puts it, hold no write permission. External plugins cannot obtain kubernetes:mutate, ops:execute or secrets:read, and cannot inject arbitrary Bash, SQL or HTTP mutations into the API process. That constraint is the design, not a missing feature.

Plugin-first means the core is supposed to stop growing

The extension model is the part of the README with the most detail, and also the part with the clearest admission attached. Plugins declare capabilities and dependencies with provides and requires, resolved at runtime. Profiles, bundles and patches let development, test and production compose different providers without environment conditionals in business code. Event modes cover observe, serial, parallel and waterfall, and the document states that high-risk gates can only be tightened, never bypassed by a plugin. Each resource domain gets its own Domain Agent (Kubernetes, database, VM/host, storage, middleware, cloud, network) that reuses shared planner, context, approval, trace, event and task plugins, then loads its own providers, executors, verifiers and skills. Every plugin manifest must declare category, domains and agents. The candid part: the README calls 5.6.0 a Plugin-first transitional architecture and says it should not be misread as all historical code having been extracted. The plugin runtime and cross-team contracts are usable; the Kubernetes loop still runs through compatibility services, and backend/app/application.py is still being reduced. The stated goal is not a rewrite but that future domain features arrive as plugins and skills with zero core changes. A roadmap document at docs/PLUGIN_FIRST_REFACTOR_ROADMAP_ZH.md holds the migration boundary and completion criteria.

Getting a local stack running

The README gives concrete commands. Backend: create a virtual environment with python3 -m venv .venv, activate it, install with python -m pip install -r requirements.txt, run the test suite with python -m pytest tests, then start the local stack with python scripts/run_local_stack.py --host 127.0.0.1 --api-port 8080. Frontend, from frontend/modern: npm ci, then npm run dev for development or npm run build for a production bundle. Before submitting anything, the documented minimum is python -m pytest tests plus npm run build in the frontend directory. Cluster onboarding accepts three routes: Rancher configuration, a pasted or uploaded kubeconfig, or an in-cluster ServiceAccount. Credentials are expected to arrive through a Kubernetes Secret, workload identity or an enterprise credential service, with ConfigMaps restricted to non-sensitive configuration. One operational detail worth flagging: writes from the plugin page are off by default and require explicit platform configuration to enable. The scalability endpoint, GET /api/harness/scalability, is the check to run before assuming a deployment can scale out.

Four ports, one replica, and an honest readiness check

The kernel pins four replaceable ports under the identifier cisre.kernel.ports/v1: an append-only Event Journal, a distributed Lease with fencing tokens, a persistent Job Queue, and a Snapshot Store supporting compare-and-swap. Agents, plugins and skills depend only on those contracts, not on PostgreSQL, Redis or Kafka specifically. The README is unusually direct about the default: the file and in-process backends suit a single replica, and the UI displays Single replica rather than misreporting distributed readiness. Running multiple replicas on local backends produces an explicit violation in the readiness check. Scaling out means swapping implementations behind the same ports (transactional event store, distributed lease, persistent queue, transactional snapshot), then horizontally scaling stateless API and worker processes. The stable semantics are listed as idempotency keys per change, only the worker holding the latest fencing token able to commit against a given target, a bounded queue that applies backpressure instead of reporting false overload, replayable events, a rebuildable read model, and version-compatible plugin protocols. This is the section that tells you the project is honest about its own maturity, which is rarer than it should be.

Where CISRE is the wrong tool

The capability table is the limitation. Kubernetes is marked as a complete loop. Database, VM/host, storage, middleware/cloud resources and network are all marked contract-ready, and the README defines that term precisely: interfaces, permissions, audit and loop semantics exist, but it does not mean a specific product is connected. The document also forbids pages from fabricating resources or health data. So if your incident surface is a MySQL cluster or a storage array, CISRE gives you a contract to implement, not a working remediation path. The plugin delivery model reinforces the cost: a domain team must produce manifest.yaml, a read-only provider, skills/<incident>/SKILL.md files, action-catalog.yaml, contract tests and a README before anything reaches production, and the recommended order ends with proving the full loop against fault injection or a sandbox target before requesting production enablement. There is also a security boundary the README states outright: the VM hosting external dynamic code is not treated as a security boundary, so high-privilege providers must be isolated in separate processes or containers. And the licence metadata is unresolved. GitHub reports NOASSERTION for this repository, which means an automated classifier could not map the licence file to a known identifier. That is a question for your legal team, not a conclusion I can draw from the material.

How this differs from a general-purpose agent harness

The README says CISRE absorbed the composition ideas of the official DeepSeek Harness while keeping an independent production execution boundary, and points to docs/DEEPSEEK_HARNESS_INTEGRATION_ZH.md and docs/DEEPSEEK_HARNESS_PARITY_MATRIX_ZH.md for the comparison. The difference in approach is where the authority sits. A general agent harness lets plugins declare tools and lets the agent loop call them; the loop is the execution path. CISRE keeps the plugin composition model (provides/requires, profiles, event modes, reversible lifecycle) but routes every side effect through a separate chain: typed action, policy and blast radius, human approval, executor, same-target readback, recovery verifier, record. An agent loop in CISRE can declare a maximum step count, delegation relationships and required services, but it cannot produce a side effect on its own. The same split shows up in observability. Agent Trace displays context summaries, model decision summaries, and skill, plugin, tool, approval, change and verification spans, but the README says it does not show raw credentials, full private chain-of-thought or unmasked prompts. If you want an agent framework where the model holds the tools, this is architecturally the opposite choice.

Maintenance surface and what to check before you commit

The upgrade cost is concentrated in the plugin protocol. The README states that breaking protocol changes must ship as a parallel v2 and must not silently alter v1 semantics, which means the compatibility burden lands on plugin authors rather than on the core. Event sourcing adds another obligation: session events are appended, masked and hash-chained, and the system supports replay, fork, resume and audit tombstone deletion, so your storage and retention policy becomes part of the operational contract. The four kernel ports mean that adopting the distributed backends later is a configuration and implementation swap rather than a rewrite, but that swap is real work you have not done yet if you start on the default single-replica backends. On licensing, the repository's licence file is not mapped to a recognised identifier by GitHub (NOASSERTION), so confirm the actual terms before shipping this inside a commercial product. Verify first, in this order: read the plugin development and team onboarding documents the README links, run python -m pytest tests and the frontend build on your own machine, and check the scalability endpoint output on the topology you intend to deploy.

Editorial conclusion

Adopt CISRE if you run Kubernetes and want a change path where a human approval, a same-target readback and a recovery verifier sit between a model suggestion and a real mutation. Do not adopt it for database, VM, storage, middleware, cloud or network remediation on the strength of the README alone: those rows are marked contract-ready, which the document explicitly says does not mean a specific product is connected. Before installing, verify two things in the repository itself: whether GET /api/harness/scalability reports Single replica on your target topology, and whether the licence file resolves the NOASSERTION string that GitHub reports for this project.

Official sources

1. Issues
2. README
3. William-Lu-stack/Flawless on GitHub