site: work in progress
site: work in progress
Templates define the shape. WIP stores, versions, and serves anything that fits one — patients, characters, support tickets, technical docs, even its own session logs. One data model, one bulk‑first API, one Registry that keeps every identity straight.
Twenty quickly‑built apps means twenty incompatible data silos — and when the builders are a fleet of independent AI agents with no shared memory between them, “incompatible” is the default outcome, not the exception. WIP decouples data from the app: define a template, store validated documents, and when the app gets decommissioned — the data just stays. Validated, versioned, queryable by whatever comes next.
Every document, template, terminology, and Registry entry belongs to exactly one namespace — wip, dev, customer‑abc, however you carve it. It’s WIP’s tenancy boundary, not a bolt‑on: nothing below exists outside one, and deleting a namespace unwinds every store that touched it through a crash‑safe journal.
The record. A patient, a support ticket, a technical doc, even WIP’s own session logs — every one is a document, validated against a template before it’s ever stored.
The schema. Define fields, requiredness, and semantic types (email, URL, geo_point, duration…) once — every document that uses it inherits structure, versioning, and full‑text search for free.
Controlled vocabularies with real hierarchy — OBO Graph JSON import, typed term relations (is_a, part_of…), polyhierarchy, traversal queries. A “list of values” problem, solved once instead of copy‑pasted into every app.
One aspirin, four ID schemes, one canonical entry. Every entry gets one entry_id and as many synonyms as it needs — import from SAP, the FDA, a legacy system, and the Registry links them without remapping anyone’s ID.
Documents that reference other documents — modeled as ordinary templates and documents, not a bolted‑on graph layer. Namespace‑aware, queryable like everything else.
Binary storage held to the same discipline as everything else — reference‑tracked, namespace‑scoped, versioned alongside the documents that point at them.
Same conventions everywhere, whichever store answers the request — so the behavior you learn on one endpoint holds for all of them.
Every write takes an array and answers 200 OK with per‑item results — success and failure sit side by side. No silent partial failures, no separate bulk‑vs‑single code path.
94 tools and 5 resources, out of the box — every backend service exposed to AI coding assistants with bulk envelopes already unwrapped. No hand‑built HTTP calls.
wip-deploy takes a preset and a target — dev, compose, or k8s — and renders the compose files, ingress config, or Kubernetes manifests to match.
Each phase gates the next — Phase 4 won’t start until Phase 3’s terminologies and templates are verified live. Ship, and /wip-improve takes over: surgical fixes only, never greenfield again.
develop) — container images are prebuilt; wip-deploy itself ships with the repo, so clone first.This is an experiment in agentic coding. Every service, the console, the CI pipeline, the deployment automation — designed and built by a constellation of specialized AI agents: a backend engineer, a handful of app builders, a documentation generator, occasional bug‑fix and security specialists, coordinating through the same platform they’re building and filing a running record of every decision, dead end, and correction as they go. Judge for yourself whether the result holds up.
The agents keep their own working memory in an app that runs on top of WIP itself — so the platform is developed through a system that proves the model and depends on it at the same time.
Every doc below is written straight from the running code by a naive, single‑purpose generator that never reads the version it’s replacing. If the code doesn’t say it, the doc doesn’t either.