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.
Authorizations
Enforced on every transport, with no exempt operation. A person's request — over the default local unix socket exactly as over a TCP listener — 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. The socket's file permissions are transport and are not an authorisation.
Query Parameters
Absolute path of the repository being answered for.
4096Body
The answer a person gave for a repository.
unknown is deliberately absent: it is the absence of an answer, not one somebody can give. So is "continue untrusted", the third exit, 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.
trusted, refused Which directory the answer is stored for. directory is the one named in repository. parent stores it for that directory's IMMEDIATE parent — the second exit, which 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.
directory, parent Response
Recorded.