Metadata-Version: 2.4
Name: vinyasar
Version: 0.3.1
Summary: Policy-driven, evidence-bound self-healing supervision for Yasarda (unified engine).
Keywords: automation,self-healing,agents,yasarda,mcp,codemod,remediation,repository
Classifier: Development Status :: 3 - Alpha
Classifier: Environment :: Console
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Programming Language :: Python :: 3.14
Classifier: Topic :: Software Development :: Version Control :: Git
Requires-Python: >=3.10
Description-Content-Type: text/markdown
Requires-Dist: jsonschema<5,>=4.23
Provides-Extra: yaml
Requires-Dist: PyYAML<7,>=6.0.2; extra == "yaml"
Provides-Extra: mcp
Provides-Extra: dev
Requires-Dist: pytest<10,>=8; extra == "dev"

# Vinyasar 0.2.1

A bounded policy-driven supervisor for Yasarda, not an autonomous code writer.
It has one mutating playbook: recover an interrupted Yasarda transaction to its
original file state. Recovery does not finish applying the interrupted patch.

The same Controller serves Python SDK, CLI and MCP. Models can propose changes,
but cannot create playbooks, change pinned roots or grant authority through MCP.

## Install

Install the supplied Yasarda 0.3.1 and Vinyasar 0.2.1 wheels into a dedicated
virtual environment. This delivery is local; it has not been published to PyPI.

```sh
python -m pip install ./yasarda-0.3.1-py3-none-any.whl ./vinyasar-0.2.0-py3-none-any.whl
vinyasar --version
vinyasar validate /private/profile.json
vinyasar inspect /private/profile.json --trigger-id review-001
```

CLI `inspect` produces a dry-run record in the configured state/report storage;
it does not repair the target. MCP `inspect_target` only inspects, without writing
reports. Review the profile's authority before invoking `vinyasar run`: a generated
profile can enable automatic recovery when setup checks consider storage eligible.

```sh
vinyasar run /private/profile.json --trigger manual --trigger-id event-001
vinyasar-mcp --config /private/profile.json
```

Reusing the same trigger replays the same run. Use a new trigger for a new health
check. All cooperating processes must share the same canonical state roots.

## Changed in this version

Fresh verification requires complete detector coverage and an exact rolled-back
receipt. Recovery preflights file counts and byte limits in Yasarda itself.
Durable run intent precedes attempt reservation; reserved uncertain actions are
not blindly reissued after a crash. Whole-target locks serialize local workers.

Retry budgets survive cosmetic profile edits. Report storage is checked before
actions. Canonical reports are staged, fsynced and published without replacement,
with recovery for recognized staging/link crash windows. Report schema v2 adds
record integrity, final issues, inspection completeness and deadline status.
Diagnostics are bounded/redacted before durable serialization. Failed MCP
reconciliation returns isError=true; replay serialization is deterministic.

## Upgrades and limits

Read [docs/UPGRADE.md](docs/UPGRADE.md) before replacing a running installation.
V1 reports are historical only. Legacy ledgers require host-only explicit
adoption. Original Yasarda 0.2.0 journals require matching-engine recovery first.

Linux/Python 3.13.5 was exercised for this iteration. Local POSIX mutation only;
no Windows mutation, macOS validation, distributed lock or same-user sandbox is
claimed. Timing is a cooperative deadline, not preemption of blocking filesystem
calls. Redaction is bounded allowlisting, not universal secret detection.

No scheduler installation, AST repair, network exporter, shell playbook, MCP
Tasks or A2A adapter was added. Builds and application performance require their
own independently authorized workers and evidence. See SAFETY.md for the boundary.


## Host initialization and pinned paths (0.2.1)

`vinyasar init` is the explicit host setup boundary. It resolves supplied path
aliases once and writes canonical absolute repository, Yasarda-state,
Vinyasar-state and report paths into a **new** profile. This includes home and
YASARDA_STATE_DIR defaults. Missing state directories are not created; the nearest
existing prefix is resolved strictly so dangling links and loops are refused.
The profile output parent must already exist and be private. Its final component
is never followed if linked and existing files are never overwritten.

Loading an existing profile does not canonicalize links away. Both the profile
file path and its configured paths must be link-free; relative configured entries
remain compatible and are interpreted relative to the canonical profile parent.
A linked `/var/...` source profile must be supplied explicitly as its canonical
`/private/var/...` path. YAML uses the same bounded regular-file loader.

`vinyasar doctor paths PROFILE` (or `vinyasar.doctor_paths(PROFILE)`) reports supplied
and canonical path names, missing locations, and private-directory permission
issues as JSON. It writes nothing, does not instantiate Controller, and never
changes modes or follows a linked profile to read it. Exit 0 means these path and
configuration checks passed; exit 2 reports a problem. The diagnostic explicitly
sets `mutation_authorized: false` and `storage_eligibility: not_assessed`.
It is not a sandbox, lock, filesystem certification, or approval to repair.

Python path semantics reference: https://docs.python.org/3.13/library/pathlib.html
(`Path.resolve(strict=True)`, strict loop and missing-path handling). Descriptor
read guards reference: https://docs.python.org/3/library/os.html (`dir_fd`,
`O_NOFOLLOW`, `O_NONBLOCK`, `fstat`). Runtime mutation/storage guards are unchanged.
