You tell an agent to use the repository's existing error format. It fixes the change. A week later, a fresh session invents a different format, and you give the same correction again.
The correction helped one task. To help the next task, it needs to become something the next agent can read.
That is the practical meaning of self improving coding in Wayari. Your repository can carry its instructions and lessons forward. The underlying models do not train themselves, and a finished job is not proof that the next job will be better.
01keep the rules beside the code
First-use repository setup adds a shared WAYARI.md guide, standing orders and a taste file. Existing agent guides point to the shared instructions. Setup adds its marked blocks without overwriting what you already wrote.
Standing orders hold decisions that should apply again. For example:
wayari standing add "Use the existing API error format for new endpoints."
Taste holds what the repository's design should feel like. Both are useful because they are explicit and inspectable. A person can correct a rule instead of hoping the right fragment survives inside a long conversation.
02keep the observation, too
An instruction tells the next agent what to do. A finding tells it what happened and where to look.
wayari finding src/api/errors.ts "The new endpoint returned a different error shape from the existing endpoints."
The persistent thread keeps the repository's record across sessions. wayari thread reads it; findings stay pinned to paths so later work can find the relevant observation.
Write what was observed. "The test timed out when the service was offline" gives the next task something to reproduce. "Make the tests better" does not.
03turn a useful lesson into a reusable skill
Some work teaches a procedure worth repeating: how this repository adds an endpoint, checks a migration, or verifies a visual change.
wayari promote <channel> --as <name> can draft a skill from a completed channel. The draft stays on the channel branch for a person to finish. It is an opportunity to turn a lesson into instructions, not an automatic endorsement of everything the previous agent did.
A skill should name when to use it, the work it requires and the evidence that says it succeeded. An anecdote becomes useful only when another session can act on it.
04check whether the next attempt improved
A stored lesson proves that something was remembered. It does not prove that the lesson helped.
For a recurring task, compare the next result with the earlier one: did the same correction recur, did the check fail again, and how much human intervention did the work need? Wayari records gate attempts, interventions and routing outcomes that can support that investigation. Keep the sample size beside any result you report.
The useful promise is that the next agent can read what earlier work learned. A stronger promise, such as "every PR gets better", needs evidence from repeated work.
You can use those records in Burst at your desk or Sunrise while you are away. The lessons belong to the repository in both cases, and the review still comes before the merge.
