Compatibility and launch status
Separate documented contracts from verified hosted behavior.
This documentation was checked against the current repository and an authenticated Minds walkthrough on September 12, 2026. Source coverage, a working documentation build, and a successful live product workflow are different kinds of evidence.
What the audit established
| Area | Evidence |
|---|---|
| Sign-in | The supplied test account reached the authenticated chat workspace |
| Helm setup | Region and name steps were exercised and captured |
| Account navigation | Organizations, settings, agent setup, and instance-dependent views were inspected |
| Organization retest | Fresh sign-in and organization listing passed after the reported IAM URL correction |
| First instance | Dedicated Firecracker creation remains unverified; initial create returned 500 |
| Connection retest | Repaired live configuration step labels snippets as templates and key minting as unavailable |
| Instance API | Every registered HTTP operation inventoried with source inputs and handler evidence |
| SDKs and terminal | Public declarations and connection paths inventoried; compatibility gaps identified |
| Runtime certification | No successful newly provisioned hosted instance, full API exercise, or Firecracker VM mapping proved in this audit |
Current issues that affect a first integration
| Area | Observed or source-confirmed limitation |
|---|---|
| Provisioning | Organization lookup is repaired and retested; dedicated Firecracker creation remains pending |
| Runtime model | Local customer creation now delegates to ensure and fails closed when unconfigured; the hosted app is reported on the earlier Render path. Firecracker lifecycle still needs proof |
| Upgrade | Local ensure integration returns Pro metadata without an explicit resize instruction; capacity changes and exact identity preservation remain unverified |
| Preflight | Still checks legacy Render/Cloudflare configuration rather than the new ensure dependency |
| Instance-owner access | Some engine controls require internal-only authority; scoped customer access to the complete instance API is not yet established |
| Helm actions | The implemented submission allowlist supports instance provisioning; arbitrary engine actions are not established |
| Agent wizard | The repaired configuration step clearly has no live key; a real durable connection is still unavailable |
| Standalone MCP | The audited backend uses in-memory storage even when an endpoint is supplied |
| CLI/SDK authentication | Default Bearer transports do not satisfy the secure daemon's required capability header |
| Settings | Failure visibility repair reported deployed; actual persistence remains unverified |
| Recovery and training | Some checkpoint and BPTT routes report acknowledgments or completion without doing the advertised work |
| Telemetry | Some statistics and region-health paths return placeholders or fallbacks |
| Management authority | Billing, region creation, and idempotency boundaries need correction and isolated verification |
| Secondary protocols | gRPC and Arrow Flight authority must be verified before public exposure |
Organization retest followed the reported deployment dpl_9qjWTeTL5oqT13aF78pgbiYxqzeV. The connection-template retest followed the reported superseding deployment dpl_GzyjT4w7buf2e1yqPKFJy6tLSJbr. Deployment IDs were supplied by the engineering coordinator; browser checks independently verified the behavior described above.
These findings were sent to the Minds engineering coordinator for fixes, validation, and redeployment. A team acknowledgment is not a closed issue. A limitation should be removed from these docs only after the repaired revision and the relevant workflow have been checked.
Go deeper
The reference intentionally includes incomplete registered endpoints so consumers can see their actual behavior. Do not treat complete route coverage as a promise that every operation is ready for production use.