Ysra Docs

Autonomy policy

The twelve settings that bound what Ysra may do without asking, how account and repository policies combine, and why a running session keeps its snapshot.

On this page

Your autonomy policy is the contract between you and Ysra: what it may do on its own, what it must ask about, and what it may never do. Safe defaults apply until you save a policy.

The account policy in Account settings: autonomy ceiling, dependency downloads and installs, delivery and unverified delivery, with unavailable choices greyed out

Workspace → Account settings. Choices the platform can't carry out yet are marked unavailable rather than accepted silently.

How policies combine#

flowchart TB
    account[Account policy] --> effective
    repo[Repository override<br/><small>only the fields it sets</small>] --> effective
    effective[Effective policy] -->|snapshot at session start| session[Session contract]
  • The account policy sets defaults for every repository.
  • A repository override changes only the fields it sets; everything else comes from the account.
  • When a session starts, the effective policy is copied into it. Editing settings later does not change a session that is already running or paused.

Settings#

Field Values Default
force_push deny, ask ask
run_tests_before_claim true true
package_installs deny, ask, allow ask
network deny, ask, allow ask
destructive_actions deny, ask ask
production_credentials deny, ask, scoped deny
delivery_mode preserve_only, push_branch, draft_pr, merge_on_green preserve_only
unverified_delivery preserve_only, draft_pr preserve_only
deployment deny, staging, ask_production deny
autonomy_ceiling suggest_only, code_then_review, draft_pr, merge_on_green, deploy_to_staging code_then_review
nightly_backlog_sweep boolean false
show_execution_rationale boolean true

Some values are stored but not yet enforced

Not every accepted value changes behaviour today. In particular, merge_on_green and deploy_to_staging do not currently perform what their names suggest. Read GET /developer/account/capabilities and treat it as the source of truth — never this table.

run_tests_before_claim is fixed on: the API rejects false.

A policy for a first rollout#

Most teams start conservative and widen one setting at a time:

Suggested starting policy
delivery_mode: draft_pr          # open a draft PR once verified
unverified_delivery: preserve_only
package_installs: ask
network: ask
destructive_actions: ask
production_credentials: deny
deployment: deny
autonomy_ceiling: draft_pr

To change it through the API, see Autonomy policy endpoints.

YsraDocs