⌘ SchemaMap

Data, access and boundaries

Understand stored metadata, what assistants see, and access boundaries for attachments, areas, OAuth and channels.

SchemaMap 0.14.0 · Updated · The editor uses Russian UI labels, shown as written.

    What is read and stored

    The main flow contains structural metadata: table and column names, types, keys, indexes and comments. Internal PostgreSQL stores areas, schemas, tasks, sheets, history and access settings. SQL text, stack traces and files are only stored as submitted analysis materials; the application does not execute user SQL or apply migrations to the explored source.

    Voluntary screenshots may contain data, so review them before upload. Synthetic examples allow only invented anonymous scalar values; never query source rows to populate them. These are separate attachments, not part of ordinary structure import.

    What an assistant receives

    MCP/REST clients read materials within granted scopes and current area roles. Image reading additionally requires screenshotsRead / schemamap:screenshots:read. Read access does not imply write access. Assistants can see submitted descriptions and SQL, so exclude secrets before sharing. A SchemaMap link alone provides no access to your application source code.

    Verify the area, start read-only and grant only required permissions. The owner revokes API keys and access through the existing application menu. The server rejects subsequent operations after revocation; robots and noindex do not enforce access rights.

    Permanent channels and private proof

    Since 0.13.0, channels do not expire through age or inactivity: expiresAt:null. Explicit revocation/rotation, owner and area rights, parent credentials and thread membership remain mandatory. Presence and task leases have independent deadlines; they neither renew nor destroy a channel.

    The client stores its own channelToken/proof privately and supplies it to discussion operations. Losing that proof is different from server channel expiration. Never borrow another token or infer access from a matching chat name. Use explicit owner recovery or a new own channel according to the contract.