Chart the fixes Secant needs before its public release

[Sandstorm831]

Destination

A second Amendment on Sequence vertical slices, refactoring gates, and legacy deletion adds the
milestone(s) for every report on this issue that needed a decision, each backed by a decision closed on this map and ready for /to-spec. A first
Amendment ships the no-decision fixes earlier. Cutting the public release follows as a human Task outside this map.

Notes

• Planning map. It produces decisions, not code. Implementation runs through the milestone loop in docs/agents/milestones.md: an Amendment adds
  a spine row, then /to-spec, /to-tickets, slices under docs/agents/slicing.md, and an audit.
• Source reports. This issue's comments hold the reports: 1 installer (moved from the original body), 2 Workflow Bundle catalog, 3 Harness
  catalog, 4 Start a Run, 5 Run Workbench, 6 Transcript, and the idea "let the agent tell Secant it is done". The
  Charting record holds what charting settled, including the no-decision fix
  list and answers to the questions the reports raised.
• Added reports. Diagnostic logging and Windows CI reliability are reports 7 and 8. They join the decision scope of the second Amendment; the CI report also identifies one direct Codex bookkeeping fix.
• Guides. OpenCode (local clone /home/rgarg/Documents/Software_Stuff/opencode) is the default answer for TUI questions: what to show,
  truncate, colour, and animate. T3 Code (local clone /home/rgarg/Documents/Software_Stuff/t3code) carries
  the same default authority for Harness orchestration, where OpenCode differs. Either yields to an ADR or to Secant's domain. Code is copied only
  through ADR 0018's vendor route for OpenCode, or with MIT attribution for T3 Code.
• Everyday versus expert information. Everyday screens show what a workflow user needs to act. Ids, processes, timestamps, discovery evidence,
  protocol names, and recovery states move to the details panel or headless diagnostics, or disappear. The Run id stays in Previous Runs and is shown
  whenever a Run leaves an active state. Glossary terms stay canonical in code and docs, and on-screen copy uses plain words.
• No Bundle coupling. Nothing in src/ branches on a Bundle's identity (slicing rule 6). Behaviour a Bundle author may switch or tune is
  declared in the Bundle manifest, and Secant parses, validates, and applies it. The Matt Bundle is one consumer of a capability, never its design
  target.
• Architecture. Every decision honours docs/agents/module-design.md, topology.md, and dependencies.md. Consult /codebase-design when a
  decision moves ownership or adds a Seam.
• Skills. Grilling tickets use /grilling and /domain-modeling. Prototype tickets use /prototype. Research tickets are resolved by /research
  subagents, whose findings land under docs/research/ on a research/<name> branch. Research reaches main through one PR merged with a
  merge commit, never squash or rebase, so the pinned links in resolution comments survive; then the branches are deleted.
• Recorded decisions in play. Surface these before superseding any, never silently:
  • ADR 0020 and the Run lifecycle glossary: an Interactive agent step ends only on a human control; no agent-emitted completion. Superseded in
    part by ADR 0032 for opted-in Steps (the agent-declared completion decision).
  • Prototype Crucible's launch and Run information architecture: the Run view is timeline-first.
  • ADR 0024: durable, live, and preview content stay visibly distinct.
  • ADR 0022's model amendments, Spec: M4, Spec: M5,
    and Declare supported models and accept a requested model at the Harness Seam #186: a Run-level immutable Requested model, effort left to the user's Harness configuration, and free-text model entry for Claude Code.
  • Establish Claude Code's viable structured transports and
    Define the truthful Harness capability and Adapter contract: the direct Claude Code CLI transport.
  • Spec: M6: the shared planning Session (story 9) and its out-of-scope line on structured
    no-work reports.
  • Establish Crucible's pre-development engineering baseline: no general architecture linter, and no
    hard size cap (file growth triggers a cohesion review). "Unused is not dead" came from the M1 audit, not this decision, and is superseded by
    the architecture-enforcement decision.
• Work-ready. A ticket is takeable once it has one ## Starting context comment and the wayfinder:context-ready label
  (docs/agents/issue-tracker.md). Whoever closes a ticket curates Starting context for each ticket it unblocks.
• Vocabulary. CONTEXT.md and its glossary clusters. Agent-declared completion, Human-declared completion, Stage, and End
  Step are glossary terms since ADR 0032 (PR docs(adr): let opted-in Interactive agent steps accept agent-declared completion (#243) #251), and Agent call since ADR 0033 (PR docs(adr): carry agent calls to Secant over a per-Session loopback MCP server (#244) #252). Steer and Interrupt are
  redefined by ADR 0035 (PR docs(adr): interrupt ends only the Turn and a mid-Turn message is a native Steer (#255) #257), and Reasoning summary is a glossary term since ADR 0036 (PR docs(adr): record ADR 0036, the Run Workbench mirrors the agent (#247) #265).

Decisions so far

• Study how OpenCode's session screen presents an agent conversation — OpenCode's session screen is an appending chat transcript with no header or timestamps; only tool output is truncated, submit never waits, Enter submits and Shift/Ctrl/Alt+Enter or Ctrl+J add a newline, the session id appears only on exit, and several of its rules need data Secant's Harness seam does not carry yet.

• Study how OpenCode's home screen offers commands, themes, and settings — OpenCode's home is a single prompt where a leading / opens a fuzzy command list and ctrl+p a full palette over one registry Secant already depends on; themes preview live, toggled preferences persist in a state-directory KV file while hand-written settings live in a read-only config, and Secant today has a fixed menu, a fixed nord theme, and no saved preferences.

• Establish which transports T3 Code uses for Claude Code and Codex, and how it switches model and effort mid-Session — T3 Code runs the user's installed claude under the Agent SDK and Codex through app-server; Codex switches model and effort per turn/start, while for Claude it relaunches with resume plus new --model/--effort from its own model manifest, at the cost of an SDK-versus-CLI version axis and claude.ai-login policy risk, and gives no stated reasons for either choice.

• Study how T3 Code turns Claude Code and Codex events into a conversation — T3 Code normalises Claude Code and Codex traffic into one server-side event union and admits only messages and meaningful activities to the thread, keeping rate limits and usage out of it, pairing tool rows by id, summarising command output, and showing sends and work client-side; Secant's seam lacks call ids, failure states, command output, a Turn-accepted event, and a rule for reasoning summaries.

• Establish whether Secant's current Harness transports can list and switch model and effort mid-Session — Codex's app-server lists models with effort levels and switches both per turn/start on its stable surface but reports little back; Claude Code's direct stream has no documented listing, switches only through /model and /effort prompt text (typed setters are SDK-internal), reports the serving model but never the effort, and lets CLAUDE_CODE_EFFORT_LEVEL override both.

• Establish how an agent inside Claude Code or Codex can call a local Secant process, and how Secant can identify the calling Session — A per-Session Secant MCP server works in both Harnesses (Claude Code via --mcp-config, Codex via per-thread thread/start config) and runs outside the command sandbox, while a secant CLI call is blocked by Codex's default sandbox; the server instance itself can identify the Session, env vars are overridable, OS peer credentials are strong only on Linux, and Codex MCP approvals would fail the Turn in today's Adapter.

• Decide how the gate enforces architecture and tells agents how to fix a violation — A dedicated structural step prints every Secant structural violation as file:line with a rule id, a code-only fix:, and a see: guidance anchor, from a typed rule catalogue; it adds a Module AGENTS.md section check and knip-enforced unused code (reversing "unused is not dead", test use still counts), fails lint on warnings, leaves size, cohesion, complexity, and classes to review, and opens the first pre-public-release milestone.

• Define agent-declared completion for Interactive agent steps — An opted-in agent calls step done or stage done with a required one-line reason, and Secant applies it as End Step, Continue, or End Stage through the same settlement as the human, only once the Turn ends cleanly; the human keeps every control, an optional agent-Iteration checkpoint (default 100, no ceiling) keeps unattended loops stopping for a human, the manifest adds agentCompletion with optional Entry Turn hint texts, and ADR 0032 supersedes ADR 0020's human-only rule while its Verdict half stands.

• Choose the channel and caller identification for agent calls to Secant — An agent calls step_done or stage_done on a Secant-hosted loopback MCP server attached to each Session that has an opted-in Step, attributed by a per-Session token to that Session's live Turn with no identity from the agent; Secant's tools are pre-approved in both Harnesses, the reply is accepted, held for review, or refused, the Harness Interface carries opaque call declarations, and Codex MCP approvals and MCP elicitations on both Harnesses stop failing Turns (ADR 0033).

• Establish how T3 Code and the native Claude Code and Codex clients interrupt a Turn and queue a message typed mid-Turn — Claude Code's Esc keeps the partial work and a mid-Turn Enter is read after the running tool calls; Codex's Enter steers over turn/steer, Tab queues client-side, and Esc interrupts with a <turn_aborted> marker; T3 Code closes and resumes the Claude query, folds a mid-Turn Codex send into the active Turn, and queues in its web client; Secant's current transports can interrupt-and-continue, inject natively (Claude Code best-effort), and queue as the next Turn without a transport change, while today it halts the Run on Interrupt, offers Claude Code no Steer, and refuses a mid-Turn send.

• Decide how model and effort are chosen and changed within a Harness Session — A Run carries one Model choice of real model and effort (no "Harness default"), preselected from the human's last choice or the Harness's own reported defaults, changeable while the Run is open and requested by every Turn in every Session; Codex applies it on the next turn/start, Claude Code takes typed set_model/apply_flag_settings at once (qualified by get_settings, --resume relaunch fallback), each Turn records requested and effective model and effort, and ADR 0034 supersedes the Run-level immutable Requested model.

• Decide how the human interrupts a Turn and sends a message while a Turn is working — Interrupt ends only the Turn: the Run waits blocked on the human, an Interactive agent step continues the same Session, and an Agent step's follow-up Turn stays in the same Attempt and advances on a clean end; a mid-Turn message is a native Steer in both Step kinds (Codex turn/steer, Claude Code a uuid-stamped stdin frame), the Turn lasts until every Steer is delivered, Interrupt drops the undelivered ones back to the compose, Claude Code stops with the raw interrupt control request (SIGTERM fallback), headless is unchanged and its gaps are listed in docs/headless-parity.md, and ADR 0035 supersedes the halting Interrupt.

• Establish how Secant can contain a Harness's descendant processes on Windows (addendum) — A Git Bash fork-and-exec leaves a dead Windows parent and escapes taskkill /T /F, including Claude Code's raw-interrupt kill. A kill-on-close Job Object that allows no breakaway contains every case and survives a Secant crash. bun:ffi CreateProcessW with a job list and node:net named-pipe stdio puts live Claude Code and Codex in it from creation. Such a job also kills processes a Harness detaches on purpose and makes their breakaway fail with error 5. Codex's turn/interrupt leaves commands running, and Git Bash cannot run in Codex's sandbox. Claude Code, OpenCode, and T3 Code rely on taskkill alone.

• Decide how the Matt Bundle adopts agent-declared completion — grill and plan-tickets opt in to step done only (grill after asking whether the human has anything left; plan-tickets on the human's approval, default text), implement opts in to both with Secant's default step text and a stageDoneWhen that fires only when no open ticket is left (none ready or unreadable: say so and stop), a 50-Iteration Review checkpoint, a new tickets Session for plan-tickets and publish-tickets, prompts stripped of "only the human ends it" lines with skills untouched, and Interactive steps still produce no Run Artifacts (a following Agent step in the same Session does).

• Prototype the Run Workbench as an agent screen — Layout B (ADR 0036): an appending agent transcript with no header, timestamps, or ids and a Steps sidebar above 120 columns; only shell output truncates, reasoning summaries show as collapsed Thought rows (not private under ADR 0022), OpenCode's scanner marks work, sends clear at once, the four interaction kinds stay distinct, keys move off bare letters, the mouse is on, the transcript overlay retires, everforest is the default theme, and ADR 0024's visibly-distinct rule becomes distinct-as-data; the seam and Projection gaps graduated into three tickets.

• Establish whether Claude Code's direct stream-json transport emits reasoning summaries, and under which setting — Direct Claude Code 2.1.283/Sonnet 4.6 emits streamed and completed summaries with showThinkingSummaries: true; false/default suppress bodies, a hidden display flag overrides it, and normal Claude/Codex summary formats supply no title or duration, with Codex raw reasoning separate.

• Decide how Secant contains a Harness's descendant processes on Windows — Process owns at-creation no-breakaway Job Object containment; Windows Interrupt confirms natively when possible, stops the whole owned tree, and exact native resume continues the conversation. Unavailable containment keeps launches available with ordinary cleanup and a polite informational notice; evidence states the active guarantee, and selective stopping that preserves background work is deferred.

• Decide what the home screen offers: commands and settings — Home is a command launcher with no slash prefix or initial selection; one catalog serves its relevance-ranked search and Ctrl+P's Themes/Quit palette, the 25 themes preview in dark/light, applied appearance survives save failure, and Preferences live in Catalog behind the shared Projection Port with headless settings and next-launch cross-process refresh.

• Decide the Harness Seam's tool, command, diff, and reasoning-summary events — Identified typed tool rows carry native outcomes, bounded optional live command output, and supplied patches; summaries inherit Harness settings with native duration only, context is reported-only, protocol noise stays out, and Projection retention/history/headless choices remain separate.

• Decide how a Turn's history grows mid-Turn in the Run Projection and headless --json — Turn rows are stored at item start and settle, never per chunk, with opaque Turn-scoped identity; one per-Session history family serves the newest 200 rows with per-row live previews (full conversation on demand from the details panel); each call keeps a 30,000-character output tail, the Turn diff collapses to changed files, transcript_entry retires, and headless stays stored-only with additive transcript fields (ADR 0039).

• Decide how typed commands work in the Run Workbench compose — One Secant-owned catalog of App commands serves a / list (first character, prefix highlight, hidden when unavailable, Secant names never forwarded, no inline arguments) and Ctrl+P; ctrl+e is End Step only and End Stage has no key; each Harness declares Harness input rules (Claude Code reserves /clear /new /reset /resume /continue /fork /model /effort /fast /config, Codex nothing), checked on sends, Steers, and Bundle prompts at build, install, launch, and Turn start, with Claude Code commands refused as mid-Turn Steers; @ mentions graduated into their own ticket (ADR 0040).

• Decide how the Run Workbench compose mentions Workspace files with @ — The @ menu searches filtered Workspace files and folders in both Harness text fields, inserts a path cue with optional textual line range, and sends the same text to both Harnesses; manually typed outside paths pass through, headless gains no picker, and neither content loading nor agent reading is guaranteed.

• Approve the first pre-public-release Amendment: the no-decision fixes — M7 adds the structural gate before the settled installer, catalog, launch, Transcript, Workbench, Matt Bundle, guidance, and interrupt/Steer fixes; the model picker and full agent-screen redesign follow in the second Amendment.

Not yet specified

• How Start a Run presents the Model choice: the preselected menus with "(latest)" Claude Code aliases, the CLAUDE_CODE_EFFORT_LEVEL lock, and
  "this model has no effort setting" (decided in ADR 0034). The Run Workbench's pending and applied display is settled by ADR 0036.

Out of scope

• Preserving background work on Windows Interrupt through selective foreground stopping: deferred to a future release, beyond this pre-public-release effort (Decide how Secant contains a Harness's descendant processes on Windows — future-version option).

• Cutting the public release itself: the human release Task through ADR 0027's protected path, after the milestones close.

• Production implementation during wayfinding.

• Adopting the Effect library: a whole-codebase paradigm change, not a pre-release fix; revisit as its own effort after the public release
  (the architecture-enforcement decision, item 15).

[Sandstorm831]

2. Workflow bundle screen search

There are a few things that is wrong and needs fixing.

• The search bar and the bundle doesn't have any separation so It's not even visible that the thing is a search-bar, it seems like some random bug. It's a visual mess, so we have to fix it.
• As we arrive on the bundle page, a bundle is already selected and we see it's details in the right box. What I want is when we arrive no bundle should be selected, instead, the cursor should be focused on the search bar as it's right now. Search and other functionality should remain same. One more thing, when we are focussed on search bar, pressing key --> end (which is the key having a right arrow and take us to the right block where details of bundles is there) shouldn't take us to the right block instead it should move the cursor to the right. Right now there is no way to move the cursor to the right apart from using ctrl + -> end which skips whole word.
• pressing down key PgDn would move the focus from search to the bundles and selects the bundle at the top as usual.

[Sandstorm831]

3. Harness details screen

• Just like 2. Workflow bundle screen search the same changes should be made here
• Why we aren't able to find claude-code models, It says free-text model entry but surely that isn't the case because as codex gives models to select from, claude-code also gives models to select from.
• the Capabilities section of the Inspector is not very readable

│Session recovery · Available
│Resume a Harness Session after process loss.
│Same-Turn steering · Unavailable
│Send guidance while the current Turn is still working.
│Turn interruption · Available with limits
│Stop the current Turn and its native work.
│Limits · SIGTERM ends the Turn and the process; the Session stays resumable.
│Tool approvals · Available
│Review tool actions raised by the Harness.
│Structured questions · Unavailable
│Answer structured questions raised by the Harness.
│Effective model · Available
│Observe the model that actually served a Turn.   

• found via PATH name 'claude', Models not yet observed -> I don't think that we need that line in the left pane where we list the models.

[Sandstorm831]

4. Start a Run

Here I will mention issues for each screen

Start a Run (step 1 of 4)

• Just one issue, Make the selected bundle standout from the rest, right now there's no way to figure out what's happening and what should I do.

Choose a Harness (step 2 of 4)

• We don't need this line Found via PATH name 'claude', everything else looks good

• ‹ Harness default › — ←/→ to choose from: Harness default, gpt-6-astra, gpt-6-sol, gpt-6-luna, gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-5.5 this is completely un-readable and incomprehensible. No-one would be able to understand what to do here. We have to make it inuitive and easy to navigate.
• there'a time when we are fetching models from the harness, during this time there should be some indication that says fetching models, please wait. As otherwise it confuses people what we do.
• For Claude-Code we need to fetch models, there are no free-text models, claude gives real models for selection. See it through please
• We are not giving anywhere to select effort, why that's the case ? You see effort is very important here as it gives how much tokens model will consume and people will want to change it at their will.

Launch inputs (step 3 of 4)

• Please make the input as an input box that wraps as a paragraph. Right now one person can only write in one single line and can't add line breaks, use different lines, paragraphs, can't see what's written at starting, we don't want that. We want it to be like an input box where person can write like a normal editor, insert lines, paragraphs, gives spaces see all the content at once and similar stuff.

The final screen looks good, I don't have any issues with it.

[Sandstorm831]

5. Run workbench ( the screen which is there a live run take it's course)

I have several issues here and would try to list all of them

• The input always shows it's your turn even when a turn is underway and model is working.

◇ Your Turn — you are driving this Session
>
  … a Turn is running

all of this creates confusion for a user should I type, but what should I type here ? We have to fix this, it should be saying something else than 'Your Turn — you are driving this Session` when turn is running and it's the agent which is working.

• Run 8ad1ceba-05f3-4fc5-a6f7-6e7c52eba121 · step 1 of 6 · live in this instance (process 54817) We don't need these metrics, a user is not concerned about these metrics. See, user is only concern is getting it's feature implemented by anyway. These metrics doesn't help. For step 1 of 6, we have to place it somewhere else.

• In the image, it's full picture of workbench. Now the important things. You have treated the timeline as a literal timeline and not as a agent screen. I pictured my tool as a mirror of the agent but with our quirks, not that we create a very unreadable timeline which is not helpful of the developer not for the user. People have already optimised for agent screen, what looks good, what doesn't, what works what doesn't and we don't put our nose in that. I am attaching a video from open-code and you can see that it looks more polished, more readable, nothing which user don't want to see.

opencode.mp4

so let's start all the major things we want.

• The truncation needs to studied as to what should be truncated and when truncated how a user should be able to see that truncated part. In the screenshot, the question itself is getting truncated, how the user is supposed to read a truncated question. We need to see opencode, how it goes about deciding what to truncate it, we're not doing this on our own, opencode will be our guide here.
• Why are you attaching the whole timeline here, we don't want to see each action with it's UTC timestamp, no one wants to see that as no-one cares. See opencode also doesn't show anything like that. It should be removed from the workbench, it serves no purpose and it takes up the space.
• Everything is of the same font-size, nothing bold, nothing highlighted, and nothing like colors which can capture attentions on important parts. This is important for our workbench to look fine, not too many colors but should be enough.

you can see in the image that how opencode handles the colors, I don't know if the harness gives us anything like this information, colors, highlight, bold, large-text or anyting like that, but opencode does it and we'll see that can we also do this thing. We'll follow opencode and an application pretty similar to us which is t3-code We should also follow this codebase as it's made by very smart developer and it already solves a lot of the problems which we are solving. Whenever you are stuck in any problem that doesn't have a straight answer and might be shared by the T3 Code, then we'll look at it for guidance.

• When I am sending, on hitting enter the input remains there and it reads sending... , can we do something about this because this looks like the tool have a bug or laggy. If we really slow, then we should make it fast, but first we have to make sure these thigns doesn't look like lags
• There's no cue when agent is working, thinking or anything, opencode have this thing at the bottom going left to right giveing the feel of that agent is working, we also need somthinb like that. see here I can't tell if it's hung, working or anything else

• here you can see that we only replace the activity in Assistant preview line instead of appending activity like opencode and all other agent TUIs, this is not right, I can't read anything and have no idea what agent is saying, or what it had done in the past, or what is being said. it should be appending to history.

2026-09-27T08:41:53.514Z iteration 1                                                                                                                        
 ● Interactive Turn · working
 ✎ Assistant preview · I’ll read the Local tracker, check which ready tickets have all blockers done, and name the chosen ticket before starting implementa…
 ↳ Activity · Codex activity: account/rateLimits/updated   

Run workbench has these, and we have to take inspiration and guidance from OpenCode where TUI related things are concerned and T3 Code where anything related to harnesses orchestration, limits and all the related things. It's not exhaustive but it's good enough list to start with.

[Sandstorm831]

6. Transcript

There are a few things I want to see so that transcript is readable and navigable.

• Long lines should be wrapped around, as right now one is not able to read anything which is larger than screen. See in the image below. Transcript is essentially useless if you can't read everything that should be there.

• There should be markers for each step and session, like something like dividers that is dividing the transcript sections from grill, spec, to-tickets and all you see. And some different dividers for dividing different agent sessions, it doesn't need to be anything very large or easily recognizable, but a simple marker/divider that any-one can see and identify that this is the same session, this is a different agent session.
• I don't understand what does that mean and it's written everywhere. ◆ Assistant · session spec and this is written at the top at the starting Session transcript · spec which I don't understand. especially what do you mean be session spec here exactly ?
• Why there is different transcript for each implenentation phase ?

Resources:
  › tracker (text)
    spec-ref (text)
    tickets-ref (text)
    Session transcript · spec
    Session transcript · implement-0.0:implement
    Session transcript · implement-1.0:implement  

does it mean that all the steps (grill to ticket creation) before the implementation phase are run in 1 agent session and each implementation ticket is run in it's own agent session ? If it's the case then bundle is not properly defined, we would need to change that.

• I also don't understand the meaning of these

Session spec · open
Session implement-0.0:implement · detached
Session implement-1.0:implement · detached    

what do you mean by open, detached and what else if possible here ?

[Sandstorm831]

Idea: let the agent tell Secant it is done

Status: rough idea, written so a reader understands it. Nothing here is decided. This note does not judge whether the idea is feasible or
whether it fits the architecture.

The problem

The Matt Front Spec Bundle's implementation stage is a human-controlled Repeat group. Each Iteration is an Interactive agent step that
implements one ready ticket in a fresh Harness Session. Only the human can move it forward: Continue opens the next Iteration, and End
Stage exits the group.

The human usually can't tell when every ticket is finished. The agent knows, because it read the tracker, found the ready ticket or found none,
and did the work. So today we ask the human for a judgement that only the agent has the information to make. The human ends up as a relay for the
agent's knowledge.

The idea in one sentence

Secant listens on a local channel that it owns. At the start of the Session, the agent is told: "when you're done, or when you find there's
nothing left to do, call this." When the agent's Turn ends, Secant checks whether that Session called. If it did, Secant moves on without
asking the human.

How it would work

1. Secant listens. Secant opens a local process-to-process channel (see below). Whether it listens all the time or only during Steps that use it is open.
2. The agent is told up front. The Session's opening instructions (for example, the Entry Turn prompt) tell the agent how to reach the
   channel and which call to make when it's finished.
3. The agent calls when finished. The agent calls in two cases: it completed its work, or it found no work to do. The call can carry a small
   payload, such as which case applies and a short reason.
4. Secant records the call against its sender. Secant links the call to the Run, Step Attempt, and Harness Session it came from.
5. The call alone changes nothing. The signal is only recorded. Secant acts on it when the Turn ends: if the Session signalled, Secant
   proceeds to the next step on the human's behalf. If it didn't, Secant waits for the human exactly as it does now.

Process-to-process communication, not a web API

The channel is meant to be native inter-process communication (IPC), meaning the agent's side talks straight to the Secant process on the same
machine. It is not meant to be a web server with REST endpoints for the agent to call over HTTP.

A web server is also just a process listening on a port, so the port isn't what makes the difference. The difference is what runs over the
connection:

• What this idea prefers: a local connection between processes that carries a small message format of our own. Examples are a local TCP
  port, a Unix domain socket, or a Windows named pipe. The goals are low latency, little overhead, and no HTTP stack.
• What it does not assume: an HTTP server with REST routes.

The channel offers several named calls. It isn't a single entry point built for a single purpose. "I'm done" is the first call it carries.
Other agent-to-Secant signals can be added to the same channel later, without building a new mechanism for each one.

Not fixed. IPC is the author's current best guess because it is fast and light. It is not a requirement. If a very small local web server
works better, for example because it's easier for an agent to call, easier to run on every platform, or easier to secure, that is welcome. The
idea only needs Secant to receive the agent's signal reliably and know which Session sent it.

Keep it general

Nothing about the mechanism is specific to tickets. The general rule: whenever Secant needs to know that an agent considers its work finished,
it asks the agent at the start to make a call on the channel. It does not ask the agent to print a marker for Secant to spot in its output, and
it does not ask the human to guess. "No tickets left" is just the first case that needs this.

Why this differs from today

• The human stops judging something they can't see. Knowing when the work is complete becomes the job of the agent, which has the memory
  and context.
• Secant doesn't read the agent's prose. The agent makes a separate, deliberate call outside the conversation text. Secant doesn't scan
  output for a phrase.
• The Turn finishes cleanly first. Secant acts only at the Turn boundary, not the moment the call arrives. The agent's Turn always ends
  normally before Secant advances.

Left open by this idea

• When the channel exists: always, only during a Run, or only during Steps that opt in.
• What the channel is: the preference is native IPC (local port, Unix domain socket, or named pipe). A tiny local web server is also open
  if it works better (see above).
• Identifying the caller: how Secant knows which Session made a call, for example an address or token handed to each Session.
• Which calls exist and what they carry: the Matt case may need two separate signals. "I finished this ticket" would act like Continue,
  and "there are no tickets left" would act like End Stage. The note may also mean one signal, "the stage is complete".
• Edge cases: the agent signals and then keeps working, signals twice, or never signals.
• The human's role: whether the human sees the signal, can override it, or can still Continue or End Stage by hand. Whether the signal
  replaces the human controls or sits beside them.

---

Original note (verbatim)

We have adapted to the current system of ending the run in interactive runs because we don't have the way to judge whether the tickets have been completed or not, right? Now the paradigm is this, humans which is currently trying to get their thing off the ground, implement their feature should not be liable to do that. It's the agent that has the memory that has the context that has everything, so it should be doing this. But how do we incorporate that thing that that agent should be able to know and end the run and all that kind of stuff. It's hard to understand. So here is what I propose. Can we do something like we will be listening on a Port? I don't know always or sometimes but we will be listening on a port and we will tell the agent that whenever you are done or when you find that no tickets are there just call to that port. with some kind of data information or whatever what will happen then whenever we receive something on that part we can map it to like from where it came that is the process or the agent session or whatever and then we can do something that when that agent session ends we can check if The agent have called to that endpoint. That port, that particular endpoint. I'm not talking about a rest kind of endpoints. I'm talking about a port which will have several other things to call. And in that way, whenever we find that yes, the agent have called on that port at that particular endpoint, it means all the tickets have been ended and we can proceed. That will eliminate any kind of need. from user to interact. How does that sound? Now don't make it completely specialized to this kind of tickets kind of thing, but think of it in a generalized way that whenever we want to know the session has ended, we don't need to ask agent to print anything on the screen. Instead we can just ask the agent at the very start that if you are done. then call this endpoint and uh yeah that will make because if that is the case the when whenever the session whenever the turn ends for that particular session we will know that no nothing is remaining and everything is settled and we can just proceed to the next step without asking human.

[Sandstorm831]

Report 1, moved verbatim from this issue's original body when the issue became the wayfinder map (2026-09-27). Reports 2–6 and the agent-done idea are the earlier comments above.

Issues

1. Curl installer command doesn't give any indication that the process is underway, or is in progress, nothing.

There's no way to tell that the Curl installer is installing, started or anything related to progress. It should give some indication that it's started or something. Also, it got hung the first time I trying installing secant, then I pressed ctrl + C and re-ran the command of which then it installed normally.