Skip to content

Nano: support Supervisor planning, specification, and archive sessions #89

Description

@RomanEmreis

Planned PR 17 of 18. Phase: N5 roles. Later release.

Series overview and full PR index: #73.

What problem does this solve?

Interactive nano can later replace an external Supervisor for planning/spec work, but enabling a UI alone does not supply the required role-specific tools and authorization.

Proposed solution

  • Implement the Supervisor adapter/profile under src/nano/ using the same engine and narrow existing registration hooks.
  • Connect taskless planning/task-definition and specification operations natively through existing enqueue/create-spec behavior.
  • Add the distinct spec-archive profile using the existing Outcome authoring/approval/archive flow; preserve the required human approval boundary.
  • Expose tools by actual session mode: taskless definition tools and archive tools are not automatically available to task-scoped sessions.
  • Maintain scoped instructions, graph/memory access, model/version/config behavior, and native integration without loopback MCP.

Acceptance criteria

  • HQ planning/task/spec/archive entry points can launch the matching native mode with correct tool visibility and guards.
  • Tests cover role mismatch, mode-scoped tool denial, duplicate/invalid task creation, specification validation, and human approval handling.
  • Archive preserves existing provenance/source policy and best-effort memory refresh; a refresh failure does not undo a successful archive.
  • Outcome content is authored only through the existing approved workflow, not by session compaction or arbitrary tools.
  • External Supervisor adapters and native Executor behavior remain unchanged.
  • Relevant tests plus cargo fmt --check, cargo clippy -- -D warnings, and cargo test pass; new feature combinations get explicit coverage where applicable.

Impact on workflow (if any)

Adds native Supervisor participation in existing planning/spec/archive workflows without introducing task states or relaxing approval semantics.

Dependencies

Implementation boundaries

Reviewer/Consultant execution, automatic task decomposition, autonomous approval of specs/Outcomes, and a second orchestrator are outside this PR.

Keep new harness implementation in src/nano/. Reuse existing Ferrus modules in place and make only the small integration changes this PR needs. Introduce src/shared/ only for an implementation actually shared by HQ and nano; preserve the existing lifecycle and graph/memory domain boundaries.

Code entry points (existing or proposed): src/nano/{agent,ferrus,instructions}.rs, existing enqueue_task/create_spec/archive_spec operations, HQ mode routing.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions