# Coverage and implementation limits

What the source-derived instance reference covers, how it is regenerated, and where the current runtime contract is incomplete.

Source: https://docs.minds.sh/docs/api/instance/coverage



## Every registration is accounted for [#every-registration-is-accounted-for]

The inventory contains **246 method/path operations on 231 distinct HTTP paths**, across 31 capability groups. It reads `build_router`, `build_inference_router`, and the merged lineage, forgetting, and quarantine routers. The MIND-emission route constant and the nested `/admin/services` prefix are resolved explicitly. Test-only routers are excluded.

Every route resolves to a handler. The reference includes the complete handler source, typed input fields, output construction expressions, direct error variants, startup registration conditions, runtime service-prefix checks, and source locations. OpenAPI covers all registered operations, while leaving dynamic or unsupported wire schemas unconstrained.

Schema coverage is deliberately separate from route coverage. Some handlers return `impl IntoResponse`, construct `serde_json::Value`, use tagged enums, or delegate serialization to other modules. The exact expressions and type declarations remain inspectable in the pages and [data-type reference](/docs/api/instance/schemas). `reference/instance/coverage.json` records the current unresolved type list and dynamic response operations.

## Incomplete behavior that must not be mistaken for success [#incomplete-behavior-that-must-not-be-mistaken-for-success]

| Operation                              | Current source behavior                                                                                                           |
| -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| `GET /v1/continual/checkpoints/status` | Returns `{"ok":true}` without reading a checkpoint.                                                                               |
| `POST /v1/continual/recover`           | Accepts a `checkpoint_id` and returns `{"ok":true}`; no restoration occurs in this handler.                                       |
| `POST /v1/continual/components`        | Accepts an `id` and acknowledges it; no component registration occurs.                                                            |
| `POST /v1/continual/components/delete` | Accepts an `id` and acknowledges it; no component removal occurs.                                                                 |
| `POST /v1/memory/vault/access-log`     | Returns an empty array; the handler is a placeholder.                                                                             |
| `POST /v1/memory/resources/chunks`     | Returns an empty array; resource chunk retrieval is not implemented here.                                                         |
| `POST /v1/snn/train/bptt`              | Constructs a trainer but does not execute a training loop. It records placeholder completed metrics and a versioned network spec. |
| `GET /v1/mcp/stats`                    | Tool count is read from the registry, but daily calls, latency, error rate, and top tools are fixed placeholder values.           |

There is no registered `POST /v1/continual/checkpoints` route for checkpoint creation in this source snapshot. A similarly named SDK method or engine method does not make that HTTP endpoint available. The reference documents existing runtime contracts rather than filling gaps with intended behavior.

## Customer proxy access is a separate layer [#customer-proxy-access-is-a-separate-layer]

The Minds web application routes instance requests through `/api/akasha`, after loading the signed-in session, active organization, and selected service. It mints a scoped capability for the upstream call. The proxy’s grant map is not identical to the daemon’s registration table.

* The proxy does not provide `x-akasha-admin-token`; ordinary proxied `/admin/*` calls do not meet the daemon operator contract.
* Cognitive and working-memory configuration handlers require internal-system authority. An owner session does not satisfy that requirement merely because the proxy grants an `admin` action.
* The proxy’s `SNN_POST_ACTIONS` table covers core network operations but omits the registered federation operations. Those paths currently receive an empty grant rather than usable federation authority.
* Some dashboard reads use fallback responses when a service is absent or returns certain errors. A rendered dashboard fallback is not proof that its upstream endpoint succeeded.

Source: `minds-ui/apps/app/app/api/akasha/proxy.ts` and `route.ts`. The handler uses the `akashaPath` rewrite query parameter; it does not depend on a catch-all route directory in this snapshot.

## Full-engine instance configuration [#full-engine-instance-configuration]

Free and Pro share the dedicated Firecracker VM instance requirement and the same engine capabilities. A reduced `AKASHA_SERVICES` list is an implementation configuration, not a plan entitlement boundary. In the current daemon, `all` or `cognitive` enables the full `ServiceConfig`; a narrow list such as `kv,memory` omits other route families at registration time.

SNN, associative memory, and continual learning do not have individual startup `ServiceGroup` CLI values in this snapshot. They are enabled by the full configuration. Deployment and service controls must be reconciled with the full-engine product requirement; source route coverage alone does not prove every provisioned instance exposes it.

Source: `ServiceGroup` and `ServiceConfig::from_groups` in `akasha-daemon/src/main.rs`.

## Maintain the reference [#maintain-the-reference]

```bash
python3 minds-docs/scripts/generate-instance-reference.py
python3 minds-docs/scripts/generate-instance-reference.py --check
```

The generator fails when it cannot resolve a registered handler, a route expression, or a route constant. `--check` compares the complete generated result without writing. Source hashes, source line references, unresolved wire types, and implementation notes are stored beside the OpenAPI document.

This is source coverage and documented behavior. Production availability, authenticated end-to-end calls, and backend fixes require separate verification.
