Agent teams
Coding agents, some delegated to their own working copies, build features. Their reports were read and tests run, but their code was not reviewed line by line. The project’s status reports say so.
About GridWeave
GridWeave is a remote device management platform that is still being built. This page says what it is for, how and by whom it is built, and where it stands.
Purpose
What GridWeave is for
GridWeave manages fleets of computers from one place. It has a server, an endpoint agent and a web application. An operator can see devices, run scripts on them, and open terminal and file sessions, with every action checked and recorded in an audit log. Several tenants can share one installation, and the database enforces the separation.
Its design rests on one idea: the agent on each machine decides for itself whether a command is allowed. Commands arrive in an envelope signed by the server, and the agent verifies it before acting. The server never sends code to the agent. The security page describes the model and the architecture page the parts.
Origin and licence
Clean-room, from a behavioural specification, under Apache-2.0
GridWeave is a clean-room rebuild. It is written from a behavioural specification of an earlier product, which describes what that product does and not how it is coded. The source of the earlier product is never opened, copied or ported, and the project enforces this with a check that fails the build if that product’s name appears outside the specification. The reason is legal standing: a product that shares no code with its predecessor can carry its own licence.
That licence is the Apache License 2.0. Dependencies are limited to permissive licences (MIT, BSD, Apache-2.0, ISC, or unmodified MPL-2.0 libraries). A build step fails on anything else, and it keeps a generated list of third-party licences.
Who
Who builds it
GridWeave is built by Cambiar. This website is a separate small project, also under Apache-2.0.
Method
How it is built
Coding agents do much of the work, under written rules, and the work is tied to requirements and tests.
Spec Kit, one feature per branch
Each feature is specified, planned and broken into tasks with Spec Kit, built on its own branch, and merged only when the local check set passes.
Wiki-driven
A knowledge base in the repository describes the architecture, components, security model and status. It is updated in the same change as the work, and a check fails when a finished feature is missing from its log.
Tests tied to requirement IDs
Requirements in the specification have identifiers. Tests name the requirements they exercise, and a matrix check fails if a cited identifier does not exist. A citation means a test exercises the requirement, not that every clause is met.
Contracts first
Interfaces are defined in OpenAPI, AsyncAPI and Protobuf files first. Generated code is never edited by hand, and a check refuses breaking API changes.
Security with the feature
Security requirements land in the same milestone as the feature they protect. Row-level security is in the migration that creates a table.
Status
Where it honestly stands
Under construction, not released. Nothing is code-signed.
Continuous integration is disabled, the Windows parts written most recently have never been run (the Windows machine has been unreachable since), and Intel AMT was tested only against a simulator. Recording and guest sharing cover terminal sessions only and were not tried with a real agent or browser; agent self-update with rollback is proven on Linux only. The product has run on one macOS machine and one Ubuntu virtual machine. The roadmap lists every milestone and gap.