> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Record a repository's instruction-file answer > Stores the answer a person gave for repo, replacing any earlier one. Only a real answer may be written: `unknown` is the absence of an answer, and recording it would be a claim nobody made. Trusting takes effect on the next turn — instruction files are read as each turn is built, so nothing needs restarting. A `trusted` answer is REFUSED, and nothing is stored, when the repository's own `.narya/config.toml` will not load, declares a rule that would grant what this machine's owner denied, or names an instruction file the repository does not carry: 422, with the path in the message. Those are the refusals opening a session in that directory already makes, made here because this answer is what arms the file — and because a stored answer can only be replaced, never withdrawn. A `refused` answer arms nothing. On a hosted home every answer is refused 422 and nothing is stored: a session there is trusted by the repository its container cloned. ## OpenAPI ````yaml /pt/openapi/v3-current/narya.yaml put /v1/repository-trust openapi: 3.1.0 info: title: Narya Host API version: 1.0.0 description: >- The contract between the Narya host and every client. On your own machine, one long-lived host serves this API over a Unix socket in your Narya home. The terminal client and the one-shot command that Lerian ships drive this API, and a client you write drives the same one. Requests authenticate with a bearer token issued by the identity provider the host is configured with. On your own machine, the host also accepts a request with no token from your own operating system user. Once signed-in work has claimed the home for an organization, it does so only while this machine is signed in to that organization. Such a request gets 401 with NRY-0011 on work that reaches your organization beyond the machine. An operation that declares another security scheme also accepts that credential. Any other request without a valid credential gets 401 with NRY-0011. A caller whose role lacks the permission an operation needs gets 403 with NRY-0028. Submitting a message returns 202 with a turn id. Everything the turn produces streams over GET /v1/events as server-sent events with a typed envelope, and a stream resumes from a Last-Event-ID header. One error envelope: code, title and message. Codes are NRY- followed by four digits. Cursors are opaque. servers: [] security: - bearerAuth: [] tags: - name: host description: The host process itself — version, uptime, mode, store. - name: sessions description: Durable conversation containers. Archive, never destroy. - name: messages description: Submitting work into a session and interrupting it. - name: events description: The server-sent event stream every client consumes. - name: lanes description: Parallel tracks inside a session — main, subagent, side. - name: agents description: Named recipes — instructions, tools, model, policy. Read-only in v1. - name: ladder description: >- What a person can type: the skills and command files in force for one repository, and expanding one into text. Five origins merged, nearest winning a name, the repository's own rungs gated on trust. - name: permissions description: Pending permission asks, decisions, and the decision audit. - name: intercom description: Sessions on one machine finding and messaging each other. - name: packages description: The one thing a user installs — resources, Go code, or both. - name: extensions description: >- Host-side extensions and the operations each exposes over the wire. This is the generic lane a host extension uses to serve its own client half (a TUI component, a web panel) or any API-only consumer, without adding routes to this contract. - name: workflows description: Deterministic multi-agent orchestration runs. - name: providers description: Model suppliers, their auth state, and the model catalogue. - name: monitors description: >- Long-running watchers a session keeps beside its conversation — a test runner in watch mode, a build, a log being followed. Started by the model or by the person, always listed, always killable. - name: records description: The queryable local record of everything that happened. - name: environments description: >- Where a session's code lives and its commands run — this machine, or a container narya operates. A session that names none runs here. - name: schedules description: >- Work the host's own clock starts with nobody present — a repository, a prompt, a rule and what one fire may spend. Cancel, never destroy. - name: sharing description: >- Publishing a session from a developer's own home to the organisation's, and what is held back before a byte leaves the machine. - name: refinements description: >- What this owner has taught narya and allowed it to keep — distilled facts, and the skills, agents and commands the model wrote for itself. Propose, read, consent, roll back. Nothing here fires until a person answers. - name: platform description: >- Calls Lerian's control plane made to a home it hosts, as this home recorded them. paths: /v1/repository-trust: put: tags: - sessions summary: Record a repository's instruction-file answer description: >- Stores the answer a person gave for repo, replacing any earlier one. Only a real answer may be written: `unknown` is the absence of an answer, and recording it would be a claim nobody made. Trusting takes effect on the next turn — instruction files are read as each turn is built, so nothing needs restarting. A `trusted` answer is REFUSED, and nothing is stored, when the repository's own `.narya/config.toml` will not load, declares a rule that would grant what this machine's owner denied, or names an instruction file the repository does not carry: 422, with the path in the message. Those are the refusals opening a session in that directory already makes, made here because this answer is what arms the file — and because a stored answer can only be replaced, never withdrawn. A `refused` answer arms nothing. On a hosted home every answer is refused 422 and nothing is stored: a session there is trusted by the repository its container cloned. operationId: putRepositoryTrust parameters: - name: repository in: query required: true description: Absolute path of the repository being answered for. schema: type: string maxLength: 4096 requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/RepositoryTrustAnswer' responses: '204': description: Recorded. '400': $ref: '#/components/responses/BadRequest' '413': $ref: '#/components/responses/RequestBodyTooLarge' '422': $ref: '#/components/responses/UnprocessableEntity' '500': $ref: '#/components/responses/InternalServerError' components: schemas: RepositoryTrustAnswer: type: object description: The answer a person gave for a repository. required: - decision properties: decision: type: string enum: - trusted - refused description: >- `unknown` is deliberately absent: it is the absence of an answer, not one somebody can give. So is "continue untrusted", and for the opposite reason: it is a choice about THIS session that is deliberately not written down, so the next session asks again. A client that takes it simply does not call this operation. scope: type: string enum: - directory - parent default: directory description: >- Which directory the answer is stored for. `directory` is the one named in `repository`. `parent` stores it for that directory's IMMEDIATE parent — the answer that covers every sibling worktree cut under it later — and ALSO for `repository` itself whenever the parent's answer would not reach it, which is when that directory carries a contrary answer of its own: nearest wins, so the parent's row alone would have left a refusal standing under a prompt whose own key line says the repository's material loads. A directory with no contrary answer gets no row of its own, so one answer still covers a whole tree. The server computes the parent rather than trusting a caller to name an ancestor, so a client cannot widen an answer past the one it offered, and it refuses `parent` with 400 wherever the GET reported none. The filesystem root is refused SEPARATELY and for every scope, the omitted one included, so naming `/` as the `repository` itself is a 400 too — a client that builds the path by joining and lets a component escape lands there without any dialogue. One `/` row answers `trusted` for every directory on the machine, permanently, with nothing that shows or revokes it; writing one by hand into the store stays the only route to it. examples: - decision: trusted - decision: trusted scope: parent Error: type: object description: >- The single error envelope every operation returns. Codes are NRY- followed by four digits and are catalogued in the top-level x-error-catalog extension. required: - code - title - message properties: code: type: string pattern: ^NRY-[0-9]{4}$ description: Machine-readable error code from the NRY catalogue. title: type: string maxLength: 256 description: Short human-readable summary of the error class. message: type: string maxLength: 4096 description: Specific, actionable description of what went wrong. fields: type: object description: Per-field validation problems. additionalProperties: type: string examples: - code: NRY-0002 title: Session not found message: >- No session with id 6b9f6d2e-1c3a-4f5b-9d7e-2a8c4e6f0b1d exists on this host. responses: BadRequest: description: Malformed request — invalid parameter, cursor, or JSON body. content: application/json: schema: $ref: '#/components/schemas/Error' RequestBodyTooLarge: description: >- The request body weighs more than this operation accepts (NRY-0024). The host holds one ceiling per operation and refuses at the door, in front of every handler: a body whose declared Content-Length is past the ceiling is refused before a byte of it is read, and a body that declares no length is read only as far as the ceiling and refused there. Nothing was read past that point and nothing was written. content: application/json: schema: $ref: '#/components/schemas/Error' UnprocessableEntity: description: The request was well-formed but failed validation. content: application/json: schema: $ref: '#/components/schemas/Error' InternalServerError: description: The host failed — including a store that refuses writes (NRY-0012). content: application/json: schema: $ref: '#/components/schemas/Error' securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT description: >- Enforced on every transport, with no exempt operation. A person's request must carry a JWT issued by the configured identity provider, which the host verifies itself against that issuer's key set: signature, issuer, expiry, and the person and organisation it names. Requests without a valid one receive 401 NRY-0011 — except a request with no token on a laptop's socket from the OS user the kernel names as the host's own, which is that machine's user. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.