> ## 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. # Read whether a repository's instruction files may be loaded > Reports the one answer stored for repo: whether its own instruction files (AGENTS.md, or CLAUDE.md when there is no AGENTS.md, plus docs/PROJECT_RULES.md) may enter the system prompt, together with which of those files the repository actually carries right now. `unknown` means nobody has been asked — an interactive client asks once and records the answer here; a non-interactive run loads nothing and says so. Both `unknown` and `refused` keep every repository-supplied file out of the prompt: a repository somebody cloned does not get to write into the model's instructions unasked. The answer is stored per canonical repository path and by that path alone — a worktree, or a subdirectory opened as its own session, answers for itself. ## OpenAPI ````yaml /en/openapi/v3-current/narya.yaml get /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. One long-lived host runs on your machine and serves this API over a Unix socket in your Narya home. Narya creates the socket owner-only, and file permissions are the whole authorization. There is no password, no token and no TLS. The terminal client and the one-shot command that Lerian ships drive this API, and a client you write drives the same one. Results never arrive on the response of the request that caused them. 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, message, and fields on 422. Codes are NRY- followed by four digits. A paged list answers items, limit and a nextCursor when more remains. Cursors are opaque. servers: [] security: [] 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: 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: 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. paths: /v1/repository-trust: get: tags: - sessions summary: Read whether a repository's instruction files may be loaded description: >- Reports the one answer stored for repo: whether its own instruction files (AGENTS.md, or CLAUDE.md when there is no AGENTS.md, plus docs/PROJECT_RULES.md) may enter the system prompt, together with which of those files the repository actually carries right now. `unknown` means nobody has been asked — an interactive client asks once and records the answer here; a non-interactive run loads nothing and says so. Both `unknown` and `refused` keep every repository-supplied file out of the prompt: a repository somebody cloned does not get to write into the model's instructions unasked. The answer is stored per canonical repository path and by that path alone — a worktree, or a subdirectory opened as its own session, answers for itself. operationId: getRepositoryTrust parameters: - name: repository in: query required: true description: Absolute path of the repository to report on. schema: type: string maxLength: 4096 responses: '200': description: The repository's trust answer and the files it would load. content: application/json: schema: $ref: '#/components/schemas/RepositoryTrust' '400': $ref: '#/components/responses/BadRequest' '500': $ref: '#/components/responses/InternalServerError' components: schemas: RepositoryTrust: type: object description: >- A repository's stored trust answer, with everything that answer governs: the instruction files that would reach the model, the repository's own command and skill directories, which the same answer loads and whose shell blocks it lets run, and its own `.narya/config.toml`, whose permission rules and hooks the same answer loads. required: - repository - decision - instructionFiles - instructionRoot - resourceDirs properties: repository: type: string maxLength: 4096 description: >- The canonical repository path the answer is stored under — absolute, with symlinks resolved, which may differ from the path the request named. instructionRoot: type: string maxLength: 4096 description: >- The directory `instructionFiles` are named relative to: the nearest enclosing git repository root at or above `repository`, or `repository` itself when it sits inside no repository. It differs from `repository` whenever a session was opened in a subdirectory of a checkout — a component of a monorepo — and a surface that asks somebody to approve these files must name this directory, because it is where they will actually be read from. The answer is still stored under `repository` alone. decision: type: string enum: - unknown - trusted - refused description: >- The EFFECTIVE answer for this directory: its own stored answer, or, when it has none, the nearest one stored above it — `inheritedFrom` says which. `unknown` when nobody has been asked for this directory or any ancestor, which is what makes an interactive client ask. `trusted` lets the instruction files below into the system prompt, loads the repository's own commands, skills, agent recipes and `.narya/config.toml`, and lifts the permission posture out of untrusted mode; `refused` keeps all of it out and stops the asking. inheritedFrom: type: string maxLength: 4096 description: >- The ancestor directory `decision` came from, when it did not come from `repository` itself. Absent means the answer is this directory's own, or that there is none. A client uses it to say WHY it is not asking — a worktree under a trusted parent is trusted without anybody being questioned about it. parent: type: string maxLength: 4096 description: >- The immediate parent of `repository`, which is the only other directory a client may offer to trust. The IMMEDIATE parent and never a grandparent, so nobody trusts their whole machine by misreading a dialogue. Absent when there is no such directory to offer: when `repository` IS the filesystem root, and when its parent WOULD BE the filesystem root — `/workspace`, `/app`, `/srv`, the usual repository mount in a container. A `/` row trusts every directory on the machine forever, so it is never one keypress away; a user who wants one writes it into the store by hand. instructionFiles: type: array description: >- The repository files the loader DISCOVERS by name, in prompt order, relative to the repository root, that would reach the model if this repository were trusted. Only files present on disk right now. An empty array does not mean nothing would reach the model: `resourceDirs` is governed by the same answer, and `projectConfig` can NAME further repository files that this array does not carry. items: type: string maxLength: 512 resourceDirs: type: array description: >- The repository's own command, skill and agent directories and its Claude Code settings file, present on disk right now, relative to `instructionRoot`, in resolution order. The SAME answer governs them, and it grants more there than it grants over instruction files: a command file under `.claude/commands` becomes typeable, and its `!`cmd`` blocks run a shell on this machine, in this repository's directory, the instant somebody types the command's name; an agent recipe under `.claude/agents` supplies the system prompt, the tool allowlist and the model a delegated turn runs under; and `.claude/settings.json`'s hook table runs shell with no trigger at all — once when the session starts, and again before every tool call, model request and tool result. A surface asking for the answer must name these too, and must ask about a repository that carries only these — no instruction files at all — because otherwise its commands, skills, recipes and hooks never load in any session. items: type: string maxLength: 512 projectConfig: type: string maxLength: 512 description: >- The repository's own `.narya/config.toml`, when it is present on disk right now — the fourth thing this one answer settles, and the one a client is most likely to miss. It declares this repository's permission rules and its hook table, and a hook runs shell with no trigger at all, so it carries the weight of `.claude/settings.json` rather than of an instruction file. Its own text never reaches the model: its rules are evaluated and its hooks run, and neither the file nor what a hook prints enters a prompt. What it can do is NAME text that does — its `instruction_files` key lists repository paths whose contents are wrapped into every turn's prompt once this repository is trusted — and those names appear neither here nor in `instructionFiles`, which carries the discovered files alone. So a surface asking for the answer must name this file, and must ask about a repository that carries only this — no discovered instruction files, no resource directories — because otherwise its rules, its hooks and the files it names never load in any session and the only signal is one warning on the first gated effect. Relative to `repository`, NOT to `instructionRoot`, which is the one entry on this response that differs: a component of a monorepo loads its own `.narya/config.toml` rather than the one at the checkout root, and a consent surface naming a file its loader will not read is the one lie it cannot afford. Absent means this repository declares nothing of its own. examples: - repository: /Users/dev/repos/midaz/components/ledger instructionRoot: /Users/dev/repos/midaz decision: unknown instructionFiles: - AGENTS.md - docs/PROJECT_RULES.md resourceDirs: - .claude/commands - .claude/skills - .claude/agents - .claude/settings.json projectConfig: .narya/config.toml 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. fields appears only on 422 validation errors, mapping each offending property to its problem. 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. Present on 422 only. 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' InternalServerError: description: The host failed — including a store that refuses writes (NRY-0012). content: application/json: schema: $ref: '#/components/schemas/Error' ````