harness-tools/docs/todos.md

Todos

Honor Bash tool working directories inside hidden worktrees

During the Orca polling fix on 02SEP2026, Bash tool calls configured with cwd beneath /srv/data/code/jb-pi/harness-tools/.worktrees/fix-orca-polling ran from the primary checkout instead. A pwd probe reproduced the mismatch, and later install and commit commands targeted the primary checkout until they were rerun with an explicit cd or git -C. The mistaken commit was reset immediately without discarding the pre-existing working changes. Reproduce this with a disposable hidden worktree and require the tool to either honor the requested directory or fail before executing the command. Cover both workspace and nested package directories; keep explicit cd and git -C as the workaround until the regression is fixed.

Merge _workflows reference runtime into workflow

extensions/_workflows was retained only as a reference while extensions/workflow was developed, but workflow still imports its runner, model, prompt, and serialization modules. Move the required code under extensions/workflow, remove obsolete model-authored workflow surfaces, update tests and documentation, and then delete the reference directory. Until that work is complete, @jbcode/pi-workflow must remain a private Bun workspace and extensions/_workflows must remain excluded from workspaces and publication. Acceptance requires bun pm pack for workflow to contain every runtime import without reaching outside the package root, followed by an isolated Pi package smoke test.

Make pi-links checks work from linked worktrees

A Slice 0 node scripts/pi-links.mjs prune --dry-run from .worktrees/nono-dynamic-permissions-slice-zero-direct exited 2 and classified every active link into the primary checkout as an outside-repository conflict. The tool anchors ownership to the current worktree root, while active links correctly target the primary repository checkout. Teach check and dry-run planning to recognize canonical checkouts sharing the same Git common directory without broadening stale-link deletion to unrelated repositories. Add linked-worktree fixtures before changing prune behavior. Until fixed, run host reconciliation only from the integrated primary checkout.

Harden Nono 0.74 command-policy and resolved-policy diagnostics

Slice 1 found two Nono 0.74 limitations while building behavioral policy proofs. First, command-policy startup fails with path must be shorter than SUN_LEN when Nono creates its supervisor socket beneath a moderately long isolated TMPDIR such as /tmp/nono-slice-one-*/sessions/personal/tmp. Before broker profiles activate command policies, reproduce the maximum safe path, then have the launcher select a private short socket root or confirm an upstream fix. Second, nono profile show --json omits resolved environment, command_policies, network.connect_port, and network.custom_credentials fields even though strict validation and live enforcement accept them. Do not treat resolved JSON as complete evidence for these capabilities; retain behavioral nono run and nono why --command proofs until the output is complete and regression-tested.

Replace workflow with a skill-based orchestrator

The strict workflow extension repeatedly failed before implementation because planner output and persisted state-machine constraints were too brittle for adaptive subagent orchestration. In a separate session, design a repository-managed skill where the main Pi agent owns the plan, task tree, isolated worktree, explicit user approval gates, verification, and independent review while launching standard scout and worker subagents directly. Preserve file-ownership boundaries, no inferred approvals, review independence, and resumable repository evidence, but prefer native Pi primitives over a custom orchestration engine. Evaluate a small committed state manifest for crash recovery before retiring or archiving the extension. Use the abandoned .worktrees/workflow-plan-seed implementation only as reference; do not integrate it by default.

Support subagent launches through multi_tool_use.parallel

A user reported that launching subagents through Pi's multi_tool_use.parallel wrapper does not work, although equivalent launches succeed outside the wrapper in another session. The tool surface in the incident below was the harness-provided functions.subagent tool wrapped by multi_tool_use.parallel; it has not been proven to be the subagent_spawn/subagent_wait surface from this repository's @jbcode/pi-subagents package. Keep those implementations separate until tracing identifies the owner.

A second incident occurred while planning the skill-led development workflow on 03SEP2026. The complete sanitized wrapper payload, prompts, expected lifecycle, observed lifecycle, and direct-launch control are retained in docs/fixtures/subagent-parallel-idle-delivery-03SEP2026.json. Environment evidence captured at 2026-09-03T15:54:57-04:00:

• Pi 0.84.4; repository subagent package 0.1.0 was present but is not yet identified as the failing tool implementation.
• Parent session 01a06885-7f00-7cff-bc2f-334984151941, file /home/jb/.pi/agent/sessions/--srv-data-code-jb-pi-harness-tools--/2026-09-03T18-26-14-400Z_01a06885-7f00-7cff-bc2f-334984151941.jsonl.
• Parent backend openai-codex/gpt-5.6-sol, reasoning high.
• One multi_tool_use.parallel call launched workflow-architecture (codebase-analyzer), workflow-history (precedent-locator), and workflow-patterns (codebase-pattern-finder) with cwd /srv/data/code/jb-pi/harness-tools. Each wrapped result returned only a successful fire-and-forget acknowledgement; no child task or session ID was exposed.
• The children later appeared completed in the UI, but their automatic result payloads did not wake the idle orchestrator. The orchestrator remained parked until the user intervened.
• Follow-up subagent_message calls for all three returned acknowledgements saying the message was delivered to a running subagent, inconsistent with the completed UI state.
• A later direct, unwrapped subagent launch named skill-workflow-plan-review in the same parent session completed and delivered its result automatically after 14 minutes 9 seconds.

Use the retained three-agent JSON payload as the captured failing fixture. Also reproduce with two minimal independent children, comparing direct calls with one wrapped call. Include a case where the parent performs other work and then becomes idle before both children finish. Preserve exact tool-call payloads, acknowledgement timestamps, child IDs when available, terminal-state timestamps, parent idle transitions, callback queue entries, and delivered steer messages. Capture whether failure occurs during schema validation, dispatch, asynchronous acknowledgement, task registration, terminal-state publication, idle-parent wake-up, or completion delivery.

The wrapper must return promptly for fire-and-forget launches, preserve each subagent's name and working directory, expose enough identity to correlate acknowledgements and terminal results, transition UI and tool-visible status consistently, and deliver each result exactly once without polling or user intervention. Add focused integration coverage for successful parallel launch, staggered completion while the parent is idle, one-child failure, cancellation, late steering of an apparently completed child, and duplicate-delivery prevention before changing either tool.

Investigate transient concurrent NeMo benchmark failures

During Dictate Phase 0 on 26AUG2026, repeated overlapping throwaway benchmark processes produced two one-off failures in the external /srv/data/tools/parakeet-v3/.venv environment:

1. ASRModel.restore_from() raised MemoryError while OmegaConf rebuilt joint.vocabulary. The exact clean/noisy/silence harness passed on its immediate rerun.
2. A later production-adapter check raised ValueError: bad marshal data (invalid reference) while importing torch._tensor. An immediate standalone import torch succeeded, and the cached _tensor.cpython-312.pyc passed marshal.loads().

The production service serializes model loading and inference and therefore does not intentionally launch concurrent NeMo processes. Before treating concurrent workers as supported, build a repeatable cold-load stress loop, monitor process and cgroup memory, disable bytecode writes, and determine whether the failures come from NeMo/OmegaConf resource pressure or concurrent access to the external environment's bytecode cache.

Repair nono self-diagnosis after terminal path drift

During Dictate waveform testing on 26AUG2026, every Unix socket bind() in services/dictate/tests/test_unix_server.py failed with EACCES or EPERM, including when TMPDIR pointed inside the repository worktree. The required diagnostic also failed:

$ nono why --self --path /tmp --op readwrite
nono: Configuration parse error: sandbox state path drifted at reload: serialized resolved=/dev/pts/15, actual resolved=/dev/null

Reproduce in a non-interactive or reloaded Pi session, determine whether /dev/pts/* should be serialized by identity rather than resolved path, and make nono why --self report the active policy even after the controlling terminal changes. Also verify whether the Pi profile intentionally denies AF_UNIX socket creation in otherwise writable paths; the Dictate service loop tests need local throwaway sockets.

Reuse the verified Dictate model during reinstall

The protocol-v2 reinstall on 26AUG2026 attempted to download the pinned model again even though the exact model already existed under ~/.local/share/pi-dictate/models/. The sandbox correctly blocked unapproved access to huggingface.co, so installation had to be repeated with the installed model passed explicitly through --model-source.

Teach services/dictate/install.sh to checksum an existing model first and keep it when it matches MODEL_SHA256. Download only when the model is absent or invalid, while preserving the current atomic temporary-file replacement for new model sources.