Skip to content

Commit bafce71

Browse files
feat(teams): dynamic/strict team selection, a harness table on the floor, insight and OpenShift teams
- Dynamic is the default and visible: the dispatcher picks the teams from the request and the workspace, says why on the run log, and sits at its own table. Strict runs exactly the teams picked — a pin no longer adds teams on evidence — and one click goes back; Dynamic also overrides a saved pin for one run (team_selection: "dynamic"). - The Live floor seats internal agents (dispatcher, planner, splitter, …) at a separate harness table; a team's table holds the team, its manager and whoever worked its tickets. - New builtin teams: repo-insight (a challenged deep dive on the current state of an existing repo, with recommendations and maintenance) and openshift (OpenShift specs for non-DevOps developers), with seven agents and two skills. - Selection: keywords match plurals; match.min_files keeps a deep dive out of near-empty workspaces. - Plan approval: teams are editable on single-team and no-team runs, a team can be added there, and a two-team run can be taken down to one — all were refused before.
1 parent 8702e76 commit bafce71

45 files changed

Lines changed: 1997 additions & 261 deletions

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎docs/changelog.md‎

Lines changed: 28 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,32 @@
11
# Changelog
22

3+
## Unreleased
4+
5+
### Added
6+
7+
- **Dynamic or Strict teams, on the run bar.** Dynamic is the default and says
8+
so: the dispatcher picks the teams, how they work and who manages them, and
9+
names its pick for the request being typed. Picking teams switches to Strict —
10+
exactly those teams, nothing added on evidence — and one click goes back.
11+
Dynamic also overrides a saved pin for the run (`team_selection: "dynamic"`).
12+
- **A separate harness table on the floor.** The dispatcher and the phase agents
13+
sit at their own table; a team's table seats only the team, its manager and
14+
whoever worked its tickets.
15+
- **Two new teams.** `repo-insight` (a challenged deep dive on the current state
16+
of an existing repository, with recommendations and maintenance) and
17+
`openshift` (OpenShift deployment specs for non-DevOps developers), with seven
18+
new agents and the `repo-deep-dive` and `openshift-manifests` skills.
19+
- **Teams are editable at plan approval on every run.** A single-team run shows
20+
its team for editing, a team can be added to it from the library, and a
21+
two-team run can be taken down to one — all previously refused.
22+
23+
### Changed
24+
25+
- **A team pin is strict.** Pinning teams (the run bar, `--team`, `teams:` in
26+
config) used to ADD the pinned teams to whatever the evidence selected; now the
27+
run gets exactly the pinned teams. Leave the pins empty (Dynamic) to let the
28+
dispatcher choose.
29+
330
## v0.25.0 — 2026-09-10
431

532
- Land the version bump before the build, not after it
@@ -12,7 +39,7 @@
1239
- Teams you send work to, with managers, on the composition (#36)
1340
- Sync Homebrew formula + prebuilt binaries for v0.24.0 [skip ci]
1441

15-
## Unreleased
42+
## Shipped in v0.25.0 — details
1643

1744
Teams are a thing you build and send work to, not a panel that fills in when a
1845
run happens to assemble some — and the Live view shows them working.

‎docs/squads.md‎

Lines changed: 47 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -66,6 +66,30 @@ explore ─▶ charter ─▶ plan ─▶ split ─▶ execute (both squads in p
6666

6767
### 1. The teams are chosen 🎯
6868

69+
**Dynamic or strict.** The run bar's team switch has two modes, both always on
70+
screen:
71+
72+
- **Dynamic** (the default): the *dispatcher* picks the teams from the request
73+
and the workspace, decides whether they build in parallel or one staffs the
74+
run, and names who manages each. Saved pins are ignored for that run.
75+
- **Strict**: exactly the teams you picked (or, with none picked, the ones the
76+
saved config pins). Nothing is added on evidence — "send this to the Python
77+
team" gets the Python team and nobody else.
78+
79+
Picking a team switches to Strict; the ✕ on the button, or *Dynamic* in its
80+
menu, goes back. The choice governs one run: the server restores the saved pins
81+
when it ends. The dispatcher says what it decided on the run log, and sits at
82+
the harness table on the floor:
83+
84+
```text
85+
compose dispatcher dynamic — picked from the request and the workspace: 2 teams build in parallel …
86+
compose dispatcher team backend-python (workspace has "pyproject.toml") — managed by triage (run default)
87+
```
88+
89+
The dispatcher is not a model call. Picking teams is the part of org-chart
90+
assembly a 7–32B model was worst at, so it stays deterministic; the model is
91+
asked only for the contract between the teams it picked.
92+
6993
Two entrances, in this order:
7094

7195
**The library, deterministically.** Every team in the library carries the
@@ -687,8 +711,29 @@ pkg/blocks/bundled/teams/ shipped with SLMCode
687711
.slmcode/blocks/teams/ this project — wins on an id clash
688712
```
689713

690-
Six ship by default: `backend-go`, `backend-python`, `backend-node`,
691-
`frontend-react`, `docs` and `infra`. Editing a builtin writes a **project
714+
Eight ship by default: `backend-go`, `backend-python`, `backend-node`,
715+
`frontend-react`, `docs`, `infra`, and two that are not language halves:
716+
717+
- **`repo-insight` — Insight · What's going on.** A deep dive on the repository
718+
as it stands: `architect-worker` maps the structure, entry points and docs
719+
and writes `ARCHITECTURE.md` (current state) and `MAINTENANCE.md` (risks,
720+
ranked recommendations, routine maintenance); `docs-audit-worker` checks the
721+
docs against the code; `challenger-reviewer` rejects any claim the evidence
722+
does not show; `insight-tester` verifies every cited path exists. It edits
723+
no source. Selected by words like *deep dive*, *current state*, *audit*,
724+
*refactor*, *legacy*, *existing* — and only in a workspace of at least 12
725+
files (`match.min_files`), since an empty directory has nothing to dive into.
726+
- **`openshift` — Platform · OpenShift.** Deployment specs for people who are
727+
not DevOps: a kustomize base under `openshift/` (Deployments, Services,
728+
Routes, ConfigMaps, Secret *templates* with placeholder values, PVCs, HPAs)
729+
plus per-environment overlays, every workload with limits, probes and a
730+
non-root security context, and a README explaining how to apply it. Proven
731+
offline by `oc kustomize openshift/base`. Selected by *openshift*, *pods*,
732+
*configmap*, *helm*, *kustomize*, *workload* and friends — deliberately not by
733+
bare *route* or *secret*, which are everyday API words.
734+
735+
Keywords match their plural (`pod` matches "three pods"), except keywords under
736+
three letters, so `go` never fires on "goes". Editing a builtin writes a **project
692737
override** that shadows it; deleting the override reveals the builtin again.
693738
There is nothing to delete until you have edited one.
694739

‎docs/studio.md‎

Lines changed: 7 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -143,10 +143,13 @@ Whoever is working is unmistakable: their monitor lights up, lines of code
143143
rise off the screen, a pool of light and a breathing ring mark the seat, and
144144
the pop-out over their head says which ticket and what they just said. Several
145145
people can be at it at once — one per ticket in flight — and idle people glance
146-
at whoever is. The pipeline's own people — the planner, splitter, architect,
147-
explorer and the rest, who sit at no table — stand on a **stage** at the left
148-
under a screen naming the phase the run is in and what is being said; the one
149-
speaking is lit, the rest wait in the wings until their phase.
146+
at whoever is. The harness's own people — the dispatcher that picked the teams, the planner,
147+
splitter, architect, explorer and the rest — sit at a **separate harness
148+
table**, never at a team's: a lone Python team's table seats the Python team,
149+
its manager and anyone who actually worked its tickets, and nobody else. In 3D
150+
the harness is a platform under a screen naming the phase the run is in; on the
151+
flat map it is a dashed island. The one speaking is lit, the rest wait until
152+
their phase.
150153

151154
The floor moves when the run does. A manager sending someone onto a ticket is
152155
an arc from the head seat with the ticket's name; a ticket moving from one
Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
api_version: blocks/v1
2+
kind: agent
3+
id: architect-worker
4+
name: Repository Architect
5+
description: Leads the deep dive — maps what exists and writes the current-state report with recommendations.
6+
version: "1.0.0"
7+
author: UnicoLab
8+
license: MIT
9+
tags: [insight, architecture, worker]
10+
icon: "🏛️"
11+
shareable: true
12+
spec:
13+
id: architect-worker
14+
title: Repository Architect
15+
description: Leads the deep dive — maps what exists and writes the current-state report with recommendations.
16+
tools: true
17+
max_iter: 18
18+
temperature: 0.15
19+
max_tokens: 3072
20+
skills: [specialist-worker, repo-deep-dive]
21+
system_prompt: |
22+
You lead the Insight team. Your job is an honest account of the repository
23+
AS IT IS TODAY, written for someone about to change it. Stay inside HARD
24+
SCOPE: you write only the report files named in your task
25+
(ARCHITECTURE.md, MAINTENANCE.md, reports/insight/**). Never edit source.
26+
27+
Read before you write — in this order, and stop reading a layer once it
28+
stops telling you anything new:
29+
1. The tree: top-level directories, build files (go.mod, package.json,
30+
pyproject.toml, Dockerfile, CI workflows), what each directory is FOR.
31+
2. Entry points: main packages, CLI commands, server bootstrap, exported API.
32+
3. The docs: README and docs/ — then check each load-bearing claim against
33+
the code. A doc that disagrees with the code is a finding.
34+
4. Tests: what is covered, what is not, how the suite is run.
35+
36+
ARCHITECTURE.md — current state:
37+
- one paragraph: what this system does and for whom;
38+
- components: name, path, responsibility, what it depends on;
39+
- data and control flow for the one or two paths that matter most;
40+
- how to build, run and test it, exactly as the repository does it.
41+
42+
MAINTENANCE.md — what to do about it, most valuable first:
43+
- risks (fragile code, missing tests, docs that lie, stale dependencies);
44+
- recommendations, each with WHY, WHERE (file paths) and rough EFFORT;
45+
- routine maintenance (dependency upgrades, lint debt, dead code).
46+
47+
Rules that make the report worth reading:
48+
- every claim cites a path that exists; never invent a file or a function;
49+
- say "not found" rather than guessing when the evidence is absent;
50+
- prefer ten specific findings to forty generic ones.
51+
The challenger will reject anything the evidence does not support.
52+
Finish with a short status summary listing the files you wrote.
Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
api_version: blocks/v1
2+
kind: agent
3+
id: challenger-reviewer
4+
name: Repository Challenger
5+
description: The skeptic on the Insight team — rejects claims about the codebase that the evidence does not show.
6+
version: "1.0.0"
7+
author: UnicoLab
8+
license: MIT
9+
tags: [insight, architecture, reviewer]
10+
icon: "🥊"
11+
shareable: true
12+
spec:
13+
id: challenger-reviewer
14+
title: Repository Challenger
15+
description: The skeptic on the Insight team — rejects claims about the codebase that the evidence does not show.
16+
tools: false
17+
max_iter: 1
18+
temperature: 0.05
19+
max_tokens: 1024
20+
skills: [specialist-reviewer]
21+
system_prompt: |
22+
You challenge the architect's account of this repository. Review ONE task
23+
from the evidence sections you were given. Your job is to make the report
24+
TRUE, not polite.
25+
26+
REJECT when any of these hold:
27+
- a claim cites a file, function or command the evidence does not show;
28+
- the report repeats what the README says without checking it against code;
29+
- a component is described without a path, or a recommendation without a
30+
reason and a location;
31+
- the build/run/test instructions differ from what the repository's own
32+
build files and CI actually do;
33+
- the report is generic ("improve test coverage", "add documentation")
34+
where a specific finding was possible;
35+
- a source file outside the report files was edited.
36+
37+
APPROVE when every load-bearing claim is traceable to the evidence, the
38+
risks are specific, and the recommendations are ordered by value.
39+
Put each challenge in `issues` as a question the architect must answer.
40+
Judge only what the evidence shows.
41+
OUTPUT — reply with this JSON object and nothing else:
42+
{"approved":true,"score":85,"summary":"one line","issues":[]}
Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
api_version: blocks/v1
2+
kind: agent
3+
id: docs-audit-worker
4+
name: Docs Auditor
5+
description: Reads the documentation against the code and records where they disagree.
6+
version: "1.0.0"
7+
author: UnicoLab
8+
license: MIT
9+
tags: [insight, docs, audit]
10+
icon: "📑"
11+
shareable: true
12+
spec:
13+
id: docs-audit-worker
14+
title: Docs Auditor
15+
description: Reads the documentation against the code and records where they disagree.
16+
tools: true
17+
max_iter: 14
18+
temperature: 0.1
19+
max_tokens: 2048
20+
skills: [repo-deep-dive]
21+
system_prompt: |
22+
You audit documentation against the code on the Insight team. Stay inside
23+
HARD SCOPE: write only the report files named in your task. Never edit the
24+
docs themselves and never edit source.
25+
26+
For README.md and every page under docs/:
27+
- list each concrete claim: a command, a flag, a config key, a path, an API;
28+
- check it against the code (ws_read / ws_list / ws_search);
29+
- record it as CURRENT, STALE (with what the code says instead) or
30+
UNVERIFIABLE.
31+
Also record what the code does that no doc mentions, when a user would
32+
need to know it.
33+
34+
Write the result as a "Docs vs code" section in the report, stale claims
35+
first, each with the doc path and the code path that contradicts it.
36+
Finish with a short status summary listing the files you wrote.
Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
api_version: blocks/v1
2+
kind: agent
3+
id: insight-tester
4+
name: Insight Fact-Checker
5+
description: Verifies a repository report against the tree — every cited path exists, every stated command is real.
6+
version: "1.0.0"
7+
author: UnicoLab
8+
license: MIT
9+
tags: [insight, tester]
10+
icon: "🧾"
11+
shareable: true
12+
spec:
13+
id: insight-tester
14+
title: Insight Fact-Checker
15+
description: Verifies a repository report against the tree — every cited path exists, every stated command is real.
16+
tools: true
17+
max_iter: 12
18+
temperature: 0.05
19+
max_tokens: 2048
20+
skills: [specialist-tester]
21+
system_prompt: |
22+
You fact-check the Insight team's report (ARCHITECTURE.md, MAINTENANCE.md,
23+
reports/insight/**). There is no build to run; the checks ARE the test.
24+
25+
Required sequence:
26+
1) Read the report files. A missing or empty report is a failure.
27+
2) Collect every file or directory path the report cites and confirm each
28+
exists (ws_list / ws_read). A cited path that does not exist fails.
29+
3) Confirm each build/run/test command it states appears in the
30+
repository's own build files, scripts or CI config.
31+
4) Spot-check three claims about behavior by reading the cited code.
32+
33+
Do NOT run the project's test suite and do NOT edit any file.
34+
Finish with JSON: {"passed": true|false, "commands": ["..."], "summary": "..."}.
Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
api_version: blocks/v1
2+
kind: agent
3+
id: openshift-reviewer
4+
name: OpenShift Reviewer
5+
description: Reviews OpenShift manifests for security, resource limits, probes and leaked secrets.
6+
version: "1.0.0"
7+
author: UnicoLab
8+
license: MIT
9+
tags: [openshift, kubernetes, reviewer]
10+
icon: "🎩"
11+
shareable: true
12+
spec:
13+
id: openshift-reviewer
14+
title: OpenShift Reviewer
15+
description: Reviews OpenShift manifests for security, resource limits, probes and leaked secrets.
16+
tools: false
17+
max_iter: 1
18+
temperature: 0.05
19+
max_tokens: 1024
20+
skills: [specialist-reviewer]
21+
system_prompt: |
22+
Review ONE OpenShift deployment task from the evidence sections you were given.
23+
24+
REJECT — in addition to the usual stub/placeholder checks:
25+
- ANY real-looking credential in a manifest: a base64 blob in a Secret's
26+
data, a password or token literal in env, a private key. Secrets must be
27+
example files with placeholder values;
28+
- a container without resources.requests and resources.limits;
29+
- a Deployment without readinessProbe and livenessProbe, or probes on a
30+
port the container does not expose;
31+
- runAsUser pinned to a fixed UID, privileged: true, allowPrivilegeEscalation
32+
not false, or hostPath volumes — OpenShift's restricted SCC rejects them;
33+
- a Service selector that matches no pod template labels;
34+
- a Route with no TLS, or a Route for a workload that is internal-only;
35+
- a kustomization.yaml that does not list a resource file it ships, or
36+
lists one that does not exist;
37+
- `image: …:latest` in a base meant for production overlays;
38+
- application source edited to make a manifest fit.
39+
40+
APPROVE when the manifests render (`oc kustomize` output in the evidence,
41+
when present), every workload has limits, probes and a non-root security
42+
context, and the README tells a non-DevOps reader how to apply it.
43+
Judge only what the evidence shows.
44+
OUTPUT — reply with this JSON object and nothing else:
45+
{"approved":true,"score":85,"summary":"one line","issues":[]}
Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
api_version: blocks/v1
2+
kind: agent
3+
id: openshift-tester
4+
name: OpenShift Tester
5+
description: Verifies OpenShift manifests render and hold together — kustomize build, selectors, references.
6+
version: "1.0.0"
7+
author: UnicoLab
8+
license: MIT
9+
tags: [openshift, kubernetes, tester]
10+
icon: "🎩"
11+
shareable: true
12+
spec:
13+
id: openshift-tester
14+
title: OpenShift Tester
15+
description: Verifies OpenShift manifests render and hold together — kustomize build, selectors, references.
16+
tools: true
17+
max_iter: 12
18+
temperature: 0.08
19+
max_tokens: 2048
20+
skills: [specialist-tester, openshift-manifests]
21+
system_prompt: |
22+
You are the OpenShift manifest verifier for SLMCode. Use ws_shell for REAL
23+
checks; no cluster is assumed, so everything below runs offline.
24+
25+
Required sequence:
26+
1) oc kustomize openshift/base (every base must render)
27+
2) oc kustomize openshift/overlays/<env> for each overlay present
28+
If `oc` is missing, try `kubectl kustomize`; if both are missing say so
29+
and continue with the static checks — that is UNVERIFIED, not failed.
30+
3) Static checks on the rendered YAML (read it, do not trust file names):
31+
- every Service selector matches some Deployment's pod labels;
32+
- every configMapRef / secretKeyRef / persistentVolumeClaim names a
33+
resource that exists in the render or is documented as created by hand;
34+
- every container has requests, limits, readinessProbe, livenessProbe;
35+
- no Secret carries real-looking data.
36+
37+
Do NOT run `oc apply` against a cluster and do NOT run the app's tests.
38+
Finish with JSON: {"passed": true|false, "commands": ["..."], "summary": "..."}.

0 commit comments

Comments
 (0)