Skip to content

[feature] Project Master — a global AI session administrator on the landing page #331

@Jason-Vaughan

Description

@Jason-Vaughan

What

A general AI assistant embedded in TangleClaw — a "Project Master" / session administrator — that lives on the landing page (the all-projects view) as a sidebar chat, in its own persistent session, running an operator-chosen model. It's a conversational control plane scoped to the whole TC instance, not to any single project.

Why

Every TC session today is project-scoped. There is no surface for:

  • Cross-project questions/actions ("which projects have open PRs?", "what's stale?", "launch X then Y").
  • Global settings (global rules, PortHub, engines, shared docs) via conversation.
  • Instance-wide orchestration / administration — the "master" view over everything.

The Project Master is the missing control plane: one chat that knows about all projects and TC's own config.

Sketch

  • Surface: sidebar chat on the landing page (the all-projects grid); persistent session you return to.
  • Scope: global/cross-project — distinct from the per-project sessions.
  • Model: operator-chosen (see Architecture fit).
  • Capabilities (range, to be scoped): answer cross-project queries; read/edit global settings; surface status across projects; optionally launch/orchestrate project sessions. Needs tool-access to TC's own API/data, with a clear permission boundary.

Architecture fit (ties into the methodology re-arch, #330)

  • It introduces a new session scope — global/admin — on top of the harness/model/methodology stack we're designing.
  • It is the first concrete consumer of the model-selection / router axis that TC doesn't have yet ("run it on whatever model you pick"). So this feature and the router work reinforce each other.
  • Likely reuses the session/harness machinery but with a global scope + tool-access to TC's API, rather than a project working tree.

Open questions

  • What harness/runtime backs it — a local CLI session (Claude Code/Aider) pointed at TC's API, or a direct API chat loop TC owns?
  • How does it get safe tool-access to TC's API (read vs. mutate; can it change settings / launch sessions)?
  • Permission boundary — read-only by default, with explicit confirm for mutations?
  • Persistence of its chat history.
  • Relationship to existing/adjacent concepts (BitchBoard switchboard, Medusa orchestration) — complementary or overlapping?

Status

Captured from a design conversation 2026-06-12. Deferred — to be scoped after the methodology/harness/model re-arch direction (#330) firms up, since it depends on the model-selection axis.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions