Team Registry: core workspace structure + team CRUD

[aselim31]

Splits from #98. Delivers the minimum registry surface that unblocks all downstream issues (#545, #600, #609, #586, #587).

Scope

• Workspace JSON structure (.dotbot/team-registry.json)
• dotbot team add <name> [--role <role>]
• dotbot team list
• dotbot team get <name>
• Schema validation + error messages

Out of scope (→ #98b)

team-remove, team-update, team-set-availability, role-list, role-create

Acceptance criteria

• team-add persists a member entry to the workspace registry
• team-list returns all members in table format
• team-get <name> returns a single member record
• All three commands pass Pester unit tests
• Unblocks #545a

Depends on

none

Blocks

#98b · #545a · #600 · #609

[tarikcosovic97]

I am available to start working on this, please review and feel free to assign it to me.

If we continue with this ticket I'd want a 5min design discussion around the persistence of this data.

@aselim31 @EnmaJim @APEJimenez

[aselim31]

Hi @tarikcosovic97 assigned
Please check with @DKuleshov as well as he is working on #416 in case there any depedency?

can you write here your anlaysis , proposed solution and open questions to keep track of all here

[tarikcosovic97]

Architecture Solution Proposal

Ticket: #630 — deliver team add / list / get + workspace JSON registry.

Persistence

We should reuse existing patterns since we already have a persistence strategy:

• File: .bot/workspace/team-registry.json (single file, git-tracked; assumes ticket's .dotbot/ is a typo)
• Writer: atomic temp-file rename via the existing Write-SettingsJsonAtomic helper in Dotbot.Core.psm1
• Shape:

  { "schema_version": 1, "members": [
      { "id": "tm_a1b2c3d4", "name": "ana-smith", "role": "developer",
        "created_at": "2026-07-15T14:22:03Z", "created_by": "cli" }
  ]}
• No DB. No new persistence framework. No seed file — created on first team add.

Code layout

Location | Purpose

• src/runtime/Modules/Dotbot.TeamRegistry/ - New module. Sole writer of the registry file. Exports Read-, Add-, Get-, Assert- functions.
• src/cli/team-{add,list,get}.ps1 - Three thin CLI scripts. Parse args, call module, render via theme helpers.
• bin/dotbot.ps1 - Add Invoke-Team dispatcher + 'team' { Invoke-Team } branch.
• tests/Test-TeamRegistry.ps1 - New test file. Layer 2 unit + CLI coverage.

Validation

Small Assert-DotbotTeamMember mirroring Assert-TaskInstance. Rejects: missing required fields, malformed names (^[a-zA-Z0-9][a-zA-Z0-9._-]{0,63}$), duplicate names (case-insensitive), schema-version mismatch on read.

Test coverage

Module-level: empty-registry bootstrap, append semantics, duplicate rejection, atomic-write cleanup, concurrent-add safety.
CLI-level: add + list + get happy paths, missing-args usage output, unknown-member error.
Layer 1: output-hygiene check picks up the new scripts automatically.

Delivery order

1. Branch feat/team-registry off main
2. Commit 1: Dotbot.TeamRegistry module + module tests
3. Commit 2: three CLI scripts + dispatcher + CLI tests
4. Commit 3: README update
5. Manual smoke in the fixture, then PR

Size estimate

~250 lines production PS + ~200 lines tests. Single lane, no changes outside src/cli/, src/runtime/Modules/Dotbot.TeamRegistry/, bin/dotbot.ps1, and the new test file.

Assumptions that need confirmation (or lock-in via PR body)

1. Path is .bot/workspace/team-registry.json (not .dotbot/…)
2. Minimal member schema { id, name, role?, created_at, created_by }
3. Names are case-insensitive-unique

@aselim31 Please take a look at the "Assumptions that need confirmation" section and provide clarification on those assumptions.

Let me know if you have concerns regarding this proposed solution and whether I can start working on it.