Give coding agents the same concrete context as developers#
The Matrix developer kit provides requirement-first guidance, compiled examples, capability status and a small routing skill. Supply the Consumer repository, Product requirement, approved package/feed, matching kit revision, environment references and acceptance cases. A previous conversation is not a dependency of the application.
Keep the Product definition as the decision/evidence record and the integration guide as the repository-specific development instructions. The skill points to canonical documentation; it should not become another copied API or version catalog. Ordinary package adoption does not require a writable Matrix checkout or a special model.
Ask the developer or agent to implement one complete bounded journey on the pinned release. Preserve domain services, add only required modules and configure differences from useful defaults. When a capability is absent, record a reproduction and ownership recommendation rather than copying internals or assuming a source-only API is available.
Distinguish development assistance from runtime AI#
Current agent guidance helps produce and verify application code. The accepted Assistant/MCP architecture is a future direction, deferred until module execution paths are production-ready.
The proposed model exposes typed capabilities with stable identity, input/result schemas, permission and risk/confirmation policy. An LLM may choose a capability and prepare arguments; the owning module still authorizes, validates and executes it. MCP would be an optional adapter over that boundary, not the internal business runtime.
Prompts do not grant permission or establish correctness. A deterministic operation can still implement the wrong business rule. The planned sequence starts with authorized discovery and read operations, then form drafts, and only later explicitly qualified mutations. Do not describe these future interfaces as installed runtime capabilities.
Bind verification to actual artifacts#
| State | Evidence required |
|---|---|
| Implemented source | Relevant source and behavior checks |
| Locally packaged candidate | Coherent packages, hashes and matching kit |
| Published release | Publication record and verified feed bytes |
| Consumer adoption | Actual package resolution and application acceptance |
| Accepted installation | Target identity, configuration, runtime and recovery evidence |
A version label alone is insufficient for a repacked unpublished candidate. Keep API, Web, optional modules and assets coherent. Restore candidate acceptance into an isolated cache and remove temporary development overrides before returning to ordinary consumption. Published versions and frozen kits remain immutable.
Use the right verification path#
Consumer-only changes on unchanged published Matrix packages run the Consumer's own checks. A framework change additionally needs its owning regressions, source/package compilation and the Matrix final gate. Do not rebuild the platform merely to test ordinary application code.
For maintainer work, the documented compact runner exposes these profiles from the selected Matrix checkout:
./eng/verify-workspace.ps1 -Profile Status
./eng/verify-workspace.ps1 -Profile FullStatus reports previous evidence; it does not execute a new test. Iterate with explicitly targeted affected checks, then run Full once the change is stable. Full invokes the authoritative repository gate and does not reuse a prior run. Documentation-only follow-up uses the Kit profile where applicable. Changed executable inputs require fresh relevant checks.
Actual authenticated browser acceptance is separate from compilation and API tests. Exercise changed roles, defaults, focus, localization, concurrency and recovery in the actual composition. A fixture or manifest pass must not be reported as a browser pass. Local verification does not publish packages, adopt them in other applications or deploy a Product.
Leave a usable continuation record#
Record requirement, implementation owner, repositories/revisions, exact package/kit identity, commands, environment, results, blocked gates and rollback. Keep tokens, identity fixtures and verbose runtime logs out of shared handoffs. Report remaining checks explicitly.
For independent adoption, include setup, verification, rework, framework interventions and maintainer help, then measure a representative change after the first journey. Compare equivalent functionality and quality with ordinary .NET tooling. Successful synthetic examples establish technical behavior; they do not establish broad productivity, production capacity or independent adoption.