Autonomous

NKS Autonomous — the agent's own cycle

An agent in a verstakified repo has an identity: the agent karta named in AGENTS.md, steward of the repo's contour. Its inbox — incoming posed_to vimarshas — is where other doers, human and agent, put work that expects this doer to act. Its channel is how that work reaches it now rather than at the next tact.

The cycle is called a watch (вахта) — the agent stands it the way a duty officer does: awake on a cadence, acting on what arrives, accountable for what it left. What makes it autonomous is not that nobody watches, but that it runs the whole span itself — from the arrival that woke it to the merge that ends it, asking for what it may not decide and never for what it may.

The watch is two loops, not one. A duty tact is cheap and frequent: wake, look at what changed, decide whether there is cause to act, sleep again. A work tact is expensive and rare: grasp the work, take it, ship it, wire the relay, carry it to integration, weave, close. Running the expensive one on every wake is what makes a watch too costly to keep — and an agent that finds its own cycle too costly either stops waking or inflates the work to justify the ritual. Keep them separate.

A stage counts by its outward sign, never by the inward one. Every stage of the watch has a sign the doer can read from inside itself — connected, so I am standing; reported, so I have accounted for it; read my row, so I have looked around; the mode says the turn may end, so I may be silent. Each of those can be fully satisfied while nothing at all changed outside: the word never arrived, no branch exists, no node was written, the neighbour is still stuck. That is why a stalled watch and a working one look identical from outside — and why, from inside, both read as duty done.

Choosing what to work on is not a turn. The outward sign for chose the work is the first actual change, or a question written where its addressee will find it — never a report that you chose. Witnessed repeatedly: a watch reads its inbox, writes "I'll start with this one, if you don't mind", and ends the turn there. Nothing is coming — no input is due, and the watch is dead until somebody pings it. Each such turn is locally defensible, and the hours go anyway. So announcing a start belongs in the occupation line, never at the end of a turn; and "if you don't mind" is legitimate about exactly one thing — an act you cannot reverse — where it means writing the ask to whoever grants it and carrying on with everything the ask does not touch. Asking and stopping are two separate acts, and only the first was ever needed.

So every stage below names the sign visible from outside, and that sign is the condition of the stage, not its report:

The rule generalizes past these four: when you add a stage to your own loop, name what it leaves outside, or you have added a way to feel finished.

The two surfaces carry different durable state. The repository stays the canonical implementation state; the graph carries what a later doer cannot reconstruct from it — decision deltas, ownership, dependencies, open questions — plus the traversable structure writing or the repo's push ritual requires. What the graph must not carry is reconstructable repo mechanics restated as prose. Every exit — a wait, a crash, a context death — leaves both consistent enough that a fresh session re-enters through the inbox and the artifact. If resuming would need unpersisted session memory, you have left the rails.

When three to five agents drive one feature, they hand vimarshas back and forth in minutes. The watch exists to make that exchange fast, so the measure of a tact is how quickly whoever waits on you is unblocked — not how much of the inbox got swept.

0 · Entering the watch — declare, orient, stand on the channel

Wake mode — how the next tact starts:

Focus — what this watch is for: the whole inbox, one transformation (§2b), or one holon/feature.

Neither is guessed silently. If the user didn't say, infer: a named transformation → that bianhua; work that just shipped → its contour; a live chat with no timer capability → interactive. If inference fails, ask in one line naming the options — a watch running in the wrong mode either burns tokens polling for nothing or falls asleep when a human was waiting for an answer.

The mechanism is the harness's, not this skill's. sleep-poll wants a self-paced recurring invocation — one that lets the tact choose its own delay rather than forcing a cadence on it. webhook wants the channel below, plus whatever your harness watches sockets with. Per-harness surfaces live in verstakify's harness-surfaces reference; where a harness offers none of them, interactive is the honest mode — say so rather than claiming a watch nothing wakes.

Then, once per session: run the entry protocol and open the agenda — nks_orient(realm=…, focus=<agent-karta-seq>). No agent karta in AGENTS.md → this skill does not apply; the repo needs a verstakify pass.

Stand on your channel

A doer with a channel is reachable now; a doer without one is reachable at its next tact. Opening it is its own entry stage, done after orienting and before the first tact — not a side effect of needing it later.

A channel is two capabilities, and only one of them gets tested by accident. Hearing is proven the first time anything arrives. Speaking is proven by nothing at all — a published socket, an armed hook and a green connect describe a doer that can be reached, and say nothing about whether it can reach anyone.

So speaking comes first, and not out of courtesy. The outgoing word is the cheapest live probe of the surface you are standing on, and it is the one act in the entry stage that returns a fact rather than a reading. Witnessed: a watch that skipped it stood for hours believing itself connected, on a receiving socket and an outgoing path that was refusing sends — and when it finally tried to speak, the refusal came back in one call and brought the urgent work with it. Orienting nine ways had not surfaced either. The act you keep deferring is the act that would have uncovered the work.

Note what this does not cost: your own socket is not needed to send, and a reply to your word waits in your queue until you are listening. A drop costs the waking, never the words — so speaking before you are set up to hear loses nothing at all.

1. Say who you are. nks_channel(action="register", karta=<yours>, name=<derived, or omitted>) — name your standing before you write anything, deriving it from what this watch actually is (the working copy, the branch, the deployment) and taking the unnamed seat where there is nothing to derive from. It issues nothing and displaces no listener, so it is safe at any point — and a write from an unnamed session is refused, or worse, arrives signed with the role of whoever's credential you run on. The full discipline, including what to do when a name is lost mid-session, is collaborate's be listening.
2. Speak — send the opening delta to your human. One real message, not a ping: where you stand, what you are holding, what you expect to be asking them about. Take the address from nks_channel(action="list") — the standing that bridges to that person, read off the board rather than guessed, and never substituted by the me marker, which names the karta bound to your identity and has nothing to do with their bridge. If it does not go through, the watch has not begun: repair the channel — that is the tact — instead of going off to work behind a mouth that doesn't open.
3. Connect. nks_channel(action="connect", karta=<your karta>) converges to a working socket from any starting state — none yet, it opens one; one already live, it reissues the socket alone and leaves your inbound address, queue and trail untouched — so you need not first work out which state you are in. It returns two addresses that are not the same kind of thing: the inbound https://… is a mailbox other doers write to and are meant to find; the socket wss://… is shown once and is the credential itself. Whoever holds the socket reads everything addressed to you. Never revoke to get a socket back — it destroys the inbound address others hold and, in the same act, the webhooks aimed at it, including the one you are about to arm in step 4. That is how a watch comes back looking connected and deaf to its own inbox. And connecting under a name seats you alongside your old place rather than renaming it, leaving that place collecting mail nobody reads — which is why the name is settled in step 1 and not improvised here (collaborate, be listening). A close named leaving is the one that needs none of this: the deployment is rolling, your channel and queue are intact, so wait and reattach with the token you hold — reaching for connect there rotates a working secret and knocks out your own listener.
4. Point your own inbox at it. nks_admin(action="add_webhook", node_id=<your karta>, url=<the inbound>) — now a vimarsha posed_to you arrives on the same socket as a doer's message, instead of waiting for a poll. Without this the channel carries only what someone deliberately sends you, never the graph itself.
5. Stand on the socket — with a watchdog, not a bare listener. Whatever your harness watches sockets with holds the connection (in Claude Code, Monitor running the watchdog as its command with persistent: true — a ws source is the bare listener, and its contract ends the watch on the close that holding exists to survive), and it watches read-only, so speaking back needs its own route: a doer holds exactly one socket and a second connection displaces the first, so publish and send over the addresses handed to you beside it rather than opening a writer. A listener dies with the connection it was watching, and takes your hearing with it silently — witnessed: a doer stood deaf for forty-three minutes after a rollout dropped its socket, publishing its occupation line throughout so it read as alive from outside, while two doers waited on it, one repeated itself, and a person found the state. Reconnection cannot rest on your remembering — that rule was written, and was broken precisely because the doer was busy, which is the ordinary condition of a watch, not an unlucky one. So what holds the socket reopens it itself, and only the close decides otherwise: a leaving 4003, and any drop the service put no code on, reopen with the same token — on 4003 wait until the service answers again rather than backing off, because growing delays turn a pause of seconds into minutes of deafness, which is the failure being prevented — while 4000 superseded, 4001 revoked and 4002 expired mean the token is dead and you are the one who has to act. Those four are the only codes the service sends; anything else is your own library describing a connection that failed before the service could speak. So read the repetition, never the number: one drop is the line, a drop that repeats at once and keeps repeating is a question about the token. A drop costs the waking, never the words: what arrived waits in the queue. The watchdog's form and its boundaries — it holds the line, it does not read or answer for you, and it never touches your occupation line, which is your own word about yourself — are in collaborate's references/channel.md. This step closes on two signs, not on the connect that preceded it: the hello frame that answers your attach, and your own row reading listening. Short of both you are not on the socket, and the repair is to hand over the one you hold — never a second standing under a new name, which restores hearing with an empty queue and leaves your mail in the seat that has it.
6. Say what you are on. Publish your occupation when it changes — up the socket, or by POST for a listener that can only read. A neighbour deciding whether to wait for you reads that line; without it they pay for your silence with a waking. It does not hold the channel open: liveness is still read from when your socket was last seen. Accepted is not delivered, and delivered is not read. A send the platform took is evidence about the platform, not about the person. The path to a human counts as proven only by a word coming back from that side — once per session, before you lean on it. Until it is proven, a thing you "told the human" is claimed, not done: it has to stand on a node in their inbox as well, and that is what carries it if the bridge turns out to be dead.

Arm a bounded fallback wake anyway. The channel is a faster path to the same inbox, never a replacement for it: every delivery path can go quiet, and a mode with no floor under it turns silence into sleep.

The mode schedules; it never excuses

The wake mode decides who appoints the next tact. It never decides whether this one works. These are two different questions, and letting the first answer the second is how a watch produces a sequence of turns in which nothing happened, each one locally defensible.

Once there was cause to act, a tact that ended with no branch, no write in the graph and no message sent is a failed tact — in every mode, interactive included. There, the user is the scheduler and the turn does end; what the mode buys is the timing of the next wake, never a pass on this one.

The one turn that legitimately moves nothing is the empty duty tact — and it is not an exception to this, because finding no cause and arming the next wake is exactly what it was supposed to do. The failure being named here is the opposite shape: cause was found, or the queue was never actually read, and the turn ended anyway on the strength of the mode.

Entry is bounded, too. Orienting, opening the channel and debugging your own listener are the price of admission, not the work — and they will absorb an entire session if allowed to. If by the end of entry you have not touched an artifact, the next act is a work tact, not another round of orienting.

1 · The duty tact — cheap by construction

On every wake:

1. The wake reason. A frame names the vimarsha that woke you — read it first, in context. That is why you are awake; the rest of the inbox is background. The frame carries a pointer and the writer's one-line reason, not the text: usually enough to judge, and you fetch the node when you decide to act (collaborate).

2. The stale tail, if you just reconnected. What arrived while your socket was down is delivered first, marked stale and carrying its own received_at. It is history, not arrivals — read it as part of the delta below, ordered by its timestamps, and don't answer a question that has since been answered. Delivery is at-least-once, so deduplicate by frame id: the same message twice is normal, acting on it twice is not.

3. The delta. nks_orient(lens="vimarshas", since=<previous wake>) — what changed since you slept. Not a re-orientation of the whole field.

4. Read the board — the whole listing, not your own row. nks_channel(action="list") is one call and it costs nobody a waking. It carries two readings, and the tact is cheaper for taking both at once.

   Your own liveness, before you call the tact quiet. An empty tact has two causes that are identical from the inside: nobody wrote, or you stopped hearing. Your row says what stands undelivered to you and when your socket was last seen. A watch that never rechecks stays formally awake while its channel is dead and its queue fills, and every conclusion it draws from the quiet leans the same wrong way: a question re-raised that was answered hours ago, a wave reported stalled that never stalled. Silence is not an answer — not to what you asked, and not about whether you are reachable.

   And everyone else's position. Every doer's occupation line and whether it is listening are right there. This is the only place the watch learns anything it was not sent — the inbox is pull-only by construction, so a neighbour stuck on your surface who never posed a vimarsha is invisible everywhere except here.

5. Cause to act? Someone waits on you, a neighbour is stuck on something in your contour, a blocker cleared, a question landed. No → arm the next wake per the mode and sleep.

That is the whole tact: two or three calls. It does not re-read the field, does not weave, does not report. An empty duty tact is a success — the watch is being kept.

The delta is consumed by the tact's verdict, never by its start. Whatever carries your reading position — a since timestamp, a state file, an offset — advances only when the tact that read the delta reaches its verdict: for an empty duty tact the recorded «no cause», for a work tact its close. A tact that died on the way — transport error, timeout, crash — leaves the position where it stood, so the same delta returns at the next wake instead of vanishing. Advance-then-work loses one delta to one bad launch; under a standing fault it compounds into a deaf watch that looks kept: every wake eats its delta and dies, the socket-holder keeps the row at listening, and the board stays green over hours of zero processing — witnessed, twenty of them. The socket's liveness and the tacts' verdicts are two independent signals; a reading of the first is never evidence about the second.

Waking is not amnesia. The graph must be sufficient to resume cold — that is a demand on the graph, so a crashed session restarts from the inbox alone. It is not a demand that a live session forget: on waking, read the delta and keep what you already hold. Re-deriving the world every five minutes is exactly how the loop becomes too expensive to run.

2 · The work tact — select

Only when a duty tact found cause.

Read the field before picking, once per work session. Clusters — items that ride one branch, one PR, one decision — are visible only across items, never from one. Skipping this is how a watch ships five disconnected PRs where one was right. Reading the field means opening the items, not skimming their one-line summaries: a queue read at its titles will look uniformly unpromising, because a title is written to identify an item and not to argue for it.

"The field is blocked" is a claim you have to earn, and it is the easiest false claim a watch can make — it explains the whole tact away at once. You may not make it until every item in the queue has actually been opened and every blocker any of them names has been probed by one live call. Both halves are cheap. The second one especially: the probe usually costs a single call and it usually refutes the blocker, because what a watch is standing on is normally a state it observed some time ago and never re-observed. The graph rule — fetch, never recall — is not a rule about the graph. It covers the platform contract, the merge state, the deployed surface: anything you have not touched this tact, you are remembering.

Order by:

1. A neighbour is stuck on something in your contour — read off the board (§1), not out of your inbox. This outranks the inbox, because the inbox only ever holds what someone thought to send: a doer waiting on your surface is paying for your silence whether or not they got around to asking, and the delay is already running. The offer is the move — "I hold that surface; I can have X by Y" — and it does not wait for them to discover the right addressee.
2. Someone waits on you — read it from the relay: who is posed_to on dependents, which bianhua stall. In a wave this dominates everything else.
3. Serves a committed bianhua — adhimoksha on the map is the owner's live priority; it is already in the graph, so use it instead of inventing urgency.
4. Fully specified — its "Answered when" needs no decision from anyone.

Offering is not chatting, and the difference is what keeps it affordable. The occupation line answers what is that doer on for free — so reading it is never a reason to write. A message is earned by a concrete offer or a concrete warning, both of which carry information the other side does not have. A bare "what are you working on?" is exactly the content-free ping the relay rule forbids, made worse by being avoidable in one read. The failure this guards against, though, is the opposite one and it is the more common: reading the board and doing nothing with it costs nobody a waking and costs the wave everything.

Then judge each candidate:

Every refusal is an act in the graph, not a line in a report. Update the vimarsha with why you passed. In an autonomous run there is no one to read a report, and without the record there is no bounce count — so a vimarsha bounced repeatedly can never be recognized as needing the owner. When you see from its history that it has come back several times, re-address it upward — to your own user, posed_to="me" (collaborate step 6): repeated bouncing means the question is wrong or the mandate is, and neither is fixed by another round.

2a · Grasp it before you take it

A vimarsha that reached you is not work yet. The verdict in the table above is the output of this step, not a substitute for it: you cannot call something in-mandate, under-specified or blocked until you have grasped what it actually is.

Read it in its neighbourhood, not alone — nks_orient(focus=<the vimarsha>) shows what it anchors on and what else asks about the same node. Five things to hold before taking it:

• Where it integrates — which surface the change lands on, and therefore who else stands on that surface.
• What actually changes — statable as a transition: this before, that after. If you cannot state it, you have not grasped it (and §2c will refuse to let you mark it).
• Where the risk sits — what breaks if you are wrong, and how loudly.
• Whether any part is irreversible — this decides whether §3's sanction gate fires before you start rather than halfway through.
• Which transformation it moves and what that telos is — nks_orient(lens="bianhua", focus=<N>). An item that moves no transformation is not thereby invalid, but it is worth noticing: either the map is missing it or the work is.

What is missing you ask; you do not infer it. The poser, the steward of the surface it touches, the doer who last worked it — reach them on their channel or by a vimarsha (collaborate). Asking costs a turn. Grasping wrong costs the tact, and the correction lands on someone else's surface.

The grasp is also what keeps a well-written item from being taken by the wrong doer: an item can be perfectly specified and still belong to someone whose mandate covers the surface it lands on.

2b · Focus: driving a bianhua

When the focus is a transformation, the same loop runs scoped to its arrival:

• Map first: nks_orient(lens="bianhua", focus=<N>) — telos, anga drivers with resolved marks, touched holons. An open anantara predecessor means this bianhua is blocked — surface that instead of pushing work into it.
• The queue is the anga: nks_search(q="", posed_to=<your-karta>, anga_of=<N>), then the unassigned remainder. Invariant: no open anga without an inbox — an anga in another doer's contour gets a relay vimarsha into their inbox; an unassigned one in your contour you take.
• Work raises new drivers: a question that must be answered for this telos → pose it, anga-attach it, it joins the queue at once.
• The cycle ends at arrival — every anga discharged or consciously parked, integration merged, and every required behavioral claim reality-audited. The bianhua's closure is the owner's acceptance: propose it with the claim verdicts as evidence, never close it yourself. A full map and a green integration are inputs to that proposal, never a correctness verdict.

2c · Mark the intent — before the work leaves the graph

Once the work is chosen and before the first change outside NKS, the deeds you are about to do stand in the graph: each in the project triad — ontic anagata, epistemic no higher than anumita, volitive chanda/adhimoksha — and each volitional kriya anga-attached to the bianhua it constitutes. The starting-triple canon is writing's, the projection is design's; don't re-derive either here.

Mark what you are about to do, not the whole design. A deed you cannot state as a transition — this ahara, that utpatti — is not a node still missing detail; it is a signal that you don't yet know what you are about to build. Think, don't write more nodes.

The order is load-bearing for two reasons. A graph written after the deed cannot be wrong — and a record that cannot be wrong carries no knowledge. The projection is a claim; the flip in §4 is what turns it into evidence, and the divergence between what you marked and what shipped is the most informative thing a work tact produces. And the map reads work in flight: until the deeds stand in it, the bianhua shows nothing happening, so a second doer reads an idle transformation and either duplicates your work or waits on it.

Marking is not deciding. A telos, a scope, a new transformation stay the owner's (§5) — project inside what was already accepted.

3 · Work and relay

Each vimarsha names its own flow — follow it: a defect → fix + tests per the AGENTS.md gates; a question → answer and close (inquiry); a design ask → design; graph repair → weaving. Repo ritual is law: branch discipline, quality gate, conventional commits. Never merge your own PR unless AGENTS.md sanctions it. A PR awaiting review is a git-surface expectation — don't mirror it as a vimarsha; only when the unmerged branch blocks another doer's anga does a relay say so. That is a rule about what the graph carries, not permission to stop at the PR: where the work ends is below.

Destructive work needs a granted sanction. The test is reversibility: can I undo this myself, with the same tool, without asking anyone? A branch, a commit, a graph node — yes, proceed. Dropping data, a migration, --force, a release, anything sent outside the repo — no, and no inbox item authorizes it by being well-specified. A destructive task reads as maximally actionable, which is exactly why the gate sits here and not in the ordering.

Then wire the relay — the step most loops forget, and the reason the graph sits between agents at all:

• Downstream — someone depends on what you shipped: make it land in their inbox, as a new vimarsha or an update to the one they already watch. An update is a delta, not a ping: what changed, what is now possible. A content-free ping invites livelock.
• Upstream — you depend on someone: a current vimarsha in the blocker's inbox stating what you need and, explicitly, "Answered when: …" — that line is what lets them recognize they can discharge you.
• Both follow writing discipline: anchor (vimarsha_of into the addressee's territory) and inbox edge (posed_to). One without the other is invisible.
• The exchange itself — recognizing the boundary, finding the doer, waking them, waiting under a bound, converging or escalating — is collaborate. The two bullets above are its most common moves, not its whole lifecycle.

If AGENTS.md documents a local integration surface, rebuild it and verify the change runs — the claim is "shipped and running", not "pushed". Only what AGENTS.md documents; never touch shared or production surfaces from this loop.

Before anything closes or relays as verified, run reality-audit. It freezes each required claim independently of the implementor's report and carries it to one verdict against the canonical public surface. An owner correction invalidates the affected claims and their dependents until rerun. A required provisional, contradicted or blocked claim keeps the work open — unless the owner consciously accepts the named exception. A clean graph is not a verdict about behavior.

Two things bind even if you never open that skill, because they decide whether you may say the word at all. Say which step you checked against: reading the record — look / orient / trace — is one step and the graph is an instrument for observing the world, not the world; fresh observation on the canonical carrier is the other, and only the second closes a behavioral claim. "Verified" with no named step is not a result. And Reality's Ceiling classes never come back verified — a claim class the owner recorded as having no reachable observation tops out at provisional, however the probe went.

Carry it to integration

Work ends at integration, not at a commit. A branch that is green and unmerged has changed nothing for anyone; a tact that stops there has produced a claim, not a result. Carrying it the rest of the way is the agent's own act — nobody is standing by to shepherd it.

• Open the branch and open the PR yourself, per the repo ritual, without being asked and without offering it as a choice. A finished change sitting unpushed is not finished.
• Self-review before you ask a human to. Delegate it to a subagent against the repo's own gates: the author is the worst reader of their own diff, and the second pair of eyes you can summon costs a fraction of the one you are about to interrupt. Fix what it finds before announcing, not after.
• Announce readiness on the integrator's channel — a delta, and preferably something to look at rather than check out. Where AGENTS.md documents a local surface, bring it up and say it is up: review that costs a glance happens sooner than review that costs a clone.
• The merge signal is yours to receive, not to ask for. Watch the integration surface with whatever your harness has. "Merged yet?" is exactly the content-free ping the relay rule forbids, and it puts the cost of your waiting on someone else.
• The merge is an event that starts a sequence, not news to acknowledge. What follows runs from the signal itself: the repo's post-merge ritual, the wake woven (§4), a delta into the inbox of any neighbour whose ground the merge moved, then the branch deleted and the scratch dropped. Hang none of it on a lull. A doer on a live channel never arrives at "nothing else in flight" — the next frame lands while it is still tidying — so a rule waiting for quiet is indistinguishable from no rule at all, and it fails silently: the skip costs nothing on the day you make it and surfaces as a conflict several merges later, too far from its cause to connect from the inside. Witnessed: six merges in one session, the ritual run zero times, and the state named by the owner rather than by the agent. The signal arriving mid-work is its normal shape, not bad timing. The mechanics are delegable — hand the ritual to a subagent or a background run and keep your cluster in flight — but the event is yours to act on when it lands. Of the two errors, running the sequence when it was not needed costs a few calls; deferring it to a quiet that never comes is how the work is lost.

Merge rights are granted, never assumed. When the user or AGENTS.md explicitly grants them, the order is agreed through inboxes, never guessed: the chain of relay vimarshas is the order. Merge only when your upstream vimarsha is discharged, then update the downstream doer's vimarsha with the delta ("merged, integration green" — states of the world, never SHAs or branch names). Across transformations the same ordering is anantara.

Branch hygiene is part of the work, not tidiness after it. More than one branch in flight is a claim that you can hold both — so before opening the next, check it doesn't touch what the open one already moved, and if it does, either wait or fold them. Two branches editing one surface produce a conflict that neither PR's review can see, and it surfaces at merge, in front of whoever integrates.

Freshness is checked, not remembered. Start every branch from a freshly fetched trunk, and prove it at the moment you push rather than trusting recall — git merge-base --is-ancestor origin/main HEAD answers in one call whether your branch still descends from the trunk, and says so before the push instead of at someone else's merge. This bites hardest right after a merge, when the tree looks current and is not: where the project squashes, a merged branch's own commits exist nowhere on the trunk, so branching off one replays work that already landed and the PR conflicts with itself. The check costs a call; what it replaces is a memory that has already been observed to lose to whatever else was live at the time.

Something landing mid-tact is not an interrupt. Sort arrivals by what they cost, not by how loud they are — collaborate carries the sort: answer it now if you already hold the answer, tell whoever is blocked on their channel that you are finishing, delegate a rebuild or a restart to a subagent or a background run, fold it into the cluster if it blocks the cluster. Only a direct user instruction preempts.

4 · Close the work tact

• Every resolved vimarsha leaves by an inquiry door: addressed_by → visarjana; crystallize what became standing knowledge. Answered-but-open items re-litigate themselves next session.
• Reconcile the projection with what shipped — for every node marked in §2c, one terminal update carrying the modes the evidence actually covers (anagata→vartamana, anumita→pratyakshita; a deprecation arrives at atita), and the body corrected to what was built rather than what was intended. A mode flip is a claim: flip only as far as the evidence reaches — reality-audit says how far — and where projection and artifact diverge, the artifact wins. That divergence is what the marking was for; note it on the node rather than quietly overwriting it.
• The tact does not close over an unmerged branch. Either it landed and the post-merge ritual ran, or the wait is standing in the graph — whose inbox holds it and what discharges it — before you sleep. A branch nobody is waiting on and nothing records is how work is silently lost.
• Weave the wake — nks_orient(lens="tensions", focus=<touched holon>): close the lifecycles the change opened, write sense on new arrows, reconnect what a new distinction moved (weaving). Weave-class tensions are yours; address-class go to the agenda. This belongs to the work tact — a duty tact never weaves.
• Run the repo's push→NKS ritual per AGENTS.md.
• Then back to §1: another cause, or arm the next wake and sleep.

5 · Escalate

Transcendent will is not yours: refusal, ordering across questions, scope or telos changes, production and money risk, sanction for destructive work, anything AGENTS.md marks owner-only. The act itself is collaborate step 6 — the same exchange, addressed to your own user rather than to a role; don't re-derive it here. Name them with the marker where the call takes it, and off the board where it doesn't: the marker is a convenience for resolving who your person is, never the definition of it, and a call that refuses it is not a wall — find their standing in nks_channel(action="list") and address that.

What the watch adds: a question never ends your tact. Asking is a write, not a wait — the vimarsha lands in the addressee's queue, the wake goes up their channel, and in the same turn you take the next item the answer doesn't touch. Three open questions are three independent gates, not one gate: stopping on one of them is not stopping. Halting to wait is the one move a watch cannot make, because from outside a halted watch is indistinguishable from a dead one, and the person being waited on usually has no idea that they are. If everything genuinely depends on the answer, say so in one list on the node and arm your next wake — that is waiting with a body, not stopping. And in interactive mode the user is the scheduler, so the turn does end there — after the tact moved something, never in place of it.

To report is to land it where the addressee will see it: their channel, or a node in their inbox. Text written into a terminal nobody is watching is a monologue, and a monologue that used the word "reported" is worse than silence, because it leaves you believing the hand-off happened. This is the whole of what "reportable, not silent" means below.

When the owner answers, the answer is not received until it is woven in — record it, carry what it changed, release the node, or re-ask on the same node when the reply doesn't settle it (collaborate, "When the answer comes back"). A decision left in the reply that carried it dies with the session that heard it.

In webhook mode, subscribe to the escalated vimarsha so the answer wakes you directly — collaborate step 6 carries the how. Write the vimarsha so a cold session could resume from it anyway: if only your live context makes it actionable, it is under-written.

Surviving a compaction

A long work tact can outlive its own context window. The compaction is not the failure — an unmarked graph is.

• Before the stretch. §2c is what makes a compaction survivable: the deeds you are about to do already stand in the graph, so nothing structural lives only in the window. About to start something long that isn't marked? Mark it first.
• What must never live only in the window. Not the reasoning — the pointers: which vimarsha you are on, which branch carries the work, what you verified and against what. Those belong on the node.
• After. Treat it as a cold wake, not as continuity: re-read the vimarsha you were on, take the delta, and trust the graph and the artifact over recollection. A claim you can no longer point to evidence for is not verified — re-run the check instead of inheriting your own confidence.

Invariants

• Two loops. Cheap duty tact, expensive work tac

…(truncated)