One platform, many products, each in its own project.
A project is the scope for everything: tests, jobs, documents, environments, repository, credentials, model choice and settings. Several products run side by side on one deployment without seeing each other, and a product with needs of its own gets a walled-off integration rather than a fork of the platform.
What a product brings, what it gets.
| The vendor provides | The platform provides |
|---|---|
| a repository and a token or GitHub App | PR verdicts, issue retests, filed bugs, graduated changes on that repository |
| how the app starts, and any patches for testability | a fresh environment per commit, private, seeded, torn down |
| tests in markdown, or a brief for the agent | a catalog that grows from runs, explorations and requirements |
| optionally, the app's own MCP servers | the agent driving the product through its tools as well as its screens |
| a model key, or nothing (use the environment default) | per-project provider, harness and model, switched without a deploy |
The vendor integration seam.
Some products need something no generic tool covers. Jade needed a real event: tenant, client and event databases from staging, restored onto every fresh box so tests start from production-shaped data. That is a vendor integration: a walled-off first-party module that declares its own requirements (credentials it needs), routes, jobs and tools, and shows up on the project's Vendor tab. Exactly one module knows Jade by name; the rest of the platform does not.
The captured dumps form a durable catalog with feature filters. One can be the project's default, restored before every standard run; the chat agent can list and request them from its first turn.
1. A user submits feedback in Jade's "Help Improve Jade" wizard.
2. Jade's sweep mirrors it to a GitHub issue on mcievents/jade.
3. Jade calls the platform: POST /issues/:n/assign-agent
(API key scoped to code-changes:write, plus a callback_url)
4. The code agent proposes a change on the internal git host and
validates it on a fresh Jade booted from the branch.
5. The platform posts the signed job result to Jade's callback;
Jade re-reads the change and shows the validation recording on
the reporter's feedback page.
6. A Jade engineer reviews and graduates → a real PR closes the issue.Feedback that comes back as a pull request.
In the era of malleable software users expect the product to change for them. The bottleneck is not writing the change but proving it is safe and getting it in front of the person who owns the code. This loop does both without a person in the middle until the review, and it has run end to end on Jade's production copy of the platform.
Where it stops today
- Every signed-in dashboard user sees every project today. Per-project access control is the prerequisite before an outside vendor is given a login, and it is not built yet.
- One vendor integration exists (Jade). The seam is designed for more, but each new one is engineering work by the platform team, not self-service.
- Model credentials are shared per environment unless a project sets its own; per-vendor billing is not modelled beyond the per-job cost record.
- A vendor's environment definition, patches and uploads are maintained by the platform team with the vendor; upstream drift in the vendor's repository is what the patch-fix agent task exists for.
Questions people ask
Can several products share one deployment?
Yes. A project is the scope for everything: tests, jobs, documents, environments, repository, credentials and model choice. Products sit side by side and never see each other's data.