[AndriiPasternak31]

Summary

• Fresh installs now seed the bundled community skills source at trinity-skills v0.3.0 (was v0.2.0). The tag adds update-dashboard, the playbook the metrics tiles and the Dashboard's empty state already point users at (metric_read_service.EMPTY_METRIC_MESSAGE, DashboardPanel.vue). On v0.2.0 a fresh 1.0 install points users at a skill the Library does not have.
• Fresh-install seed only (ent#237 AC#3). Existing instances keep their row; moving them automatically is ent#529 (not this PR). The user doc now gives the manual steps.
• No runtime code change beyond the default: the seed and the annotated-tag peel (bug(skills): a tag-pinned source is refused as moved on every sync after the first when the tag is annotated #2550) already handle v0.3.0 (annotated tag 9119c0d7 → commit 7b2aa266).

Release-note line (AC4): Bundled community skills catalog now trinity-skills v0.3.0 for new installs (adds update-dashboard, assignable to an agent from the Library). The four removed installers (add-backlog, add-project-management, add-canon, add-orchestrator) remain installable from the abilities marketplace as /agent-dev:<name>. Existing installs keep their current pin; to adopt v0.3.0, an admin first unassigns any of the four removed installers, then updates the bundled source's ref with PUT /api/skills/sources/{id} and runs a full library sync; the steps are in docs/user-docs/automation/skills-and-playbooks.md (supply-chain section).

Changes

• src/backend/config.py: DEFAULT_SKILL_SOURCE_REF default v0.2.0 → v0.3.0; the comment names why (chore(skills): bump the bundled community-catalog pin to trinity-skills v0.3.0 (lockstep with the library release) #3123) and the three files that move together.
• .env.example: the documented example is v0.3.0.
• docs/user-docs/automation/skills-and-playbooks.md: the pin line says v0.3.0. It now says that removing and re-adding the source is not an upgrade (a re-added source is always custom: it loses the bundled badge and gets custom-source priority). It also adds the steps to move an existing instance to a newer tag: unassign dropped skills first, find the is_default row, PUT the ref, run a full sync (only a full sync starts the fleet re-inject), check, roll back.
• tests/unit/test_2545_skill_source_pin.py:
  • the floor rises to (0, 3, 0) and the floor test is renamed test_default_pin_is_at_least_the_floor_release;
  • new test_user_doc_states_the_same_default (the doc must contain exactly one `vX.Y.Z` of `trinity-skills` phrase, equal to the config default);
  • the _FLOOR comment carries the membership and supply-chain commands to run before the next bump.
• tests/registry.json: registers the pin guard (it was never registered).
• docs/memory/feature-flows/skills-library-sync.md history row + footer; docs/memory/feature-flows.md Recent Updates row.
• Compose files: no change needed. docker-compose.yml, docker-compose.prod.yml and docker-compose.hosted.yml only pass TRINITY_DEFAULT_SKILL_SOURCE_REF through by name; none carries a value.
• Left alone on purpose:
  • docs/user-docs/guides/building-agents.md ("v0.2.0 and later" is still true: the backlog / project-* runtime skills are in v0.3.0);
  • docs/user-docs/whats-new/v0.9.5.md (a historical note);
  • the frontend/MCP/static-check mocks that name the add-* skills (self-contained fixtures).

#3123 acceptance criteria

• AC1 Default = v0.3.0, and the seed note shows it. test_default_pin_is_at_least_the_floor_release (floor v0.3.0) and test_seed_note_reports_the_configured_ref, plus proof B below (the seed note prints @ v0.3.0).
• AC2 A fresh sync succeeds, repeat syncs stay pinned with no moved_tag, a lost checkout recovers, and the Library holds 38 skills including update-dashboard. See proofs A and B below; both show the opposite on unmodified dev.
• AC3 Every other mention says v0.3.0: config.py, .env.example and the user doc, with parity enforced by test_env_example_documents_the_same_default and the new test_user_doc_states_the_same_default. The compose files are pass-through (above).
• AC4 The release-note line is above.

Red first, per commit: the test commit makes the floor test red against v0.2.0. The pin commit makes it green and turns the user-doc parity test red. The docs commit makes all green. The reverse direction (config back to v0.2.0 with the doc at v0.3.0) reddens all three static checks.

Proof (network clone + a throwaway SQLite file; no stack)

Captured at a0db2032d. The branch's one later commit changes only docs.

A. Clone-class proof. The platform's own SkillSourceClone, against the real upstream tag, four syncs. The script exits 0 only if every check holds; --break flips one expectation and must exit 1.

A: branch → PASS, exit 0

pin: github.com/abilityai/trinity-skills @ v0.3.0
  PASS no shell override set (found: [])
  PASS config ref is literally v0.3.0 (got 'v0.3.0')
1st: True cloned 7b2aa266d6cf None
  PASS sync 1 succeeds as `cloned`
  PASS checked-out commit is 7b2aa266 (got 7b2aa266d6cf)
2nd: True pinned 7b2aa266d6cf None None
  PASS sync 2nd succeeds as `pinned`, no moved_tag
  PASS sync 2nd returns 7b2aa266 (got 7b2aa266d6cf)
3rd: True pinned 7b2aa266d6cf None None
  PASS sync 3rd succeeds as `pinned`, no moved_tag
  PASS sync 3rd returns 7b2aa266 (got 7b2aa266d6cf)
4th (lost checkout): True cloned 7b2aa266d6cf None
  PASS sync 4 (lost checkout) succeeds as `cloned`
  PASS sync 4 returns 7b2aa266 (got 7b2aa266d6cf)
skills: 38 | update-dashboard: True
removed still present: []
  PASS 38 skills (got 38)
  PASS update-dashboard is in the tree
  PASS none of the four add-* installers is present
RESULT: PASS (0 failed)
exit=0

A′: --break → FAIL, exit 1 (the exit status can fail)

removed still present: []
  FAIL 39 skills (got 38)
  PASS update-dashboard is in the tree
  PASS none of the four add-* installers is present
RESULT: FAIL (1 failed)
exit=1

A0: control on unmodified dev → FAIL (8 failed), exit 1

pin: github.com/abilityai/trinity-skills @ v0.2.0
  PASS no shell override set (found: [])
  FAIL config ref is literally v0.3.0 (got 'v0.2.0')
1st: True cloned 9d4516be6a33 None
  PASS sync 1 succeeds as `cloned`
  FAIL checked-out commit is 7b2aa266 (got 9d4516be6a33)
2nd: True pinned 9d4516be6a33 None None
  PASS sync 2nd succeeds as `pinned`, no moved_tag
  FAIL sync 2nd returns 7b2aa266 (got 9d4516be6a33)
3rd: True pinned 9d4516be6a33 None None
  PASS sync 3rd succeeds as `pinned`, no moved_tag
  FAIL sync 3rd returns 7b2aa266 (got 9d4516be6a33)
4th (lost checkout): True cloned 9d4516be6a33 None
  PASS sync 4 (lost checkout) succeeds as `cloned`
  FAIL sync 4 returns 7b2aa266 (got 9d4516be6a33)
skills: 41 | update-dashboard: False
removed still present: ['add-backlog', 'add-canon', 'add-orchestrator', 'add-project-management']
  FAIL 38 skills (got 41)
  FAIL update-dashboard is in the tree
  FAIL none of the four add-* installers is present
RESULT: FAIL (8 failed)
exit=1

B. Fresh-install path end to end.

• Setup: a fresh SQLite file with TRINITY_DEFAULT_SKILL_SOURCE* unset; import database runs the real seed.
• Sync: SkillService.sync_library() runs into a temp library root. The Redis sync lock fails open by design.
• Checks: the recorded per-source status and the merged Library listing.

B: branch → PASS, exit 0

single-flight lock skills:library:sync acquire failed-open (Error 61 connecting to localhost:6390. Connection refused.)
  PASS no override env set (found: [])
  PASS TRINITY_DB_PATH is a fresh file (<tmp>/t.db)
[ent#237] Fresh install: seeded default skills source github.com/abilityai/trinity-skills @ v0.3.0 (admin can disable or remove it in Settings).
seeded rows: [('src_6a47ed534db2c57b', 'Trinity Community Skills', 'github.com/abilityai/trinity-skills', 'v0.3.0', 'tag', True, True)]
  PASS exactly one source, and it is the bundled default
  PASS seeded ref is v0.3.0 (got 'v0.3.0')
  PASS seeded ref_type is tag (got 'tag')
sync_library: {'success': True, 'synced': 1, 'failed': 0, 'skill_count': 38, 'shadowed_count': 0, 'commit_changed': True, 'commit_sha': '7b2aa266d6cf', 'last_sync': '2026-10-06T22:46:18.796931+00:00', 'error': None}
  PASS sync_library succeeds
recorded: success 7b2aa266d6cf
  PASS recorded last_sync_status is success (got 'success')
  PASS recorded commit is 7b2aa266 (got '7b2aa266d6cf')
library: 38 | update-dashboard: True | removed present: []
  PASS 38 skills in the Library (got 38)
  PASS update-dashboard is listed
  PASS none of the four add-* installers is listed
RESULT: PASS (0 failed)
exit=0

B0: control on unmodified dev → FAIL (5 failed), exit 1

single-flight lock skills:library:sync acquire failed-open (Error 61 connecting to localhost:6390. Connection refused.)
  PASS no override env set (found: [])
  PASS TRINITY_DB_PATH is a fresh file (<tmp>/t.db)
[ent#237] Fresh install: seeded default skills source github.com/abilityai/trinity-skills @ v0.2.0 (admin can disable or remove it in Settings).
seeded rows: [('src_bdba2c3653543840', 'Trinity Community Skills', 'github.com/abilityai/trinity-skills', 'v0.2.0', 'tag', True, True)]
  PASS exactly one source, and it is the bundled default
  FAIL seeded ref is v0.3.0 (got 'v0.2.0')
  PASS seeded ref_type is tag (got 'tag')
sync_library: {'success': True, 'synced': 1, 'failed': 0, 'skill_count': 41, 'shadowed_count': 0, 'commit_changed': True, 'commit_sha': '9d4516be6a33', 'last_sync': '2026-10-06T22:46:21.341670+00:00', 'error': None}
  PASS sync_library succeeds
recorded: success 9d4516be6a33
  PASS recorded last_sync_status is success (got 'success')
  FAIL recorded commit is 7b2aa266 (got '9d4516be6a33')
library: 41 | update-dashboard: False | removed present: ['add-backlog', 'add-canon', 'add-orchestrator', 'add-project-management']
  FAIL 38 skills in the Library (got 41)
  FAIL update-dashboard is listed
  FAIL none of the four add-* installers is listed
RESULT: FAIL (5 failed)
exit=1

Membership check (the _FLOOR comment's command, against both tags):

$ git -C ts.git ls-tree --name-only -r v0.3.0 skills/update-dashboard/SKILL.md
skills/update-dashboard/SKILL.md
$ git -C ts.git ls-tree --name-only -r v0.2.0 skills/update-dashboard/SKILL.md
$                                   # (prints nothing: v0.2.0 lacks it)

Supply chain: what v0.3.0 brings into a fleet (reviewed peeled SHA 7b2aa266)

$ git diff --stat v0.2.0 v0.3.0 -- ':!*.md'
 8 files changed, 726 deletions(-)          # all eight: templates of the four removed add-* installers
$ git diff --name-status v0.2.0 v0.3.0      # 13 .md added/modified, 26 files deleted
A  skills/update-dashboard/SKILL.md
M  README.md, skills/add-git-sync/SKILL.md, skills/add-pipeline/{SKILL.md,templates/pipeline-recover.md,templates/pipeline-tick.md},
   skills/adjust-playbook/SKILL.md, skills/agent-fleet-analysis/SKILL.md, skills/agent-fleet-migrate/SKILL.md,
   skills/create-playbook/{SKILL.md,templates/autonomous-template.md,templates/gated-template.md}, skills/project-steward/SKILL.md
D  skills/add-backlog/**, skills/add-canon/**, skills/add-orchestrator/**, skills/add-project-management/**
$ git diff v0.2.0 v0.3.0 | grep -E '^\+.*https?://'
$                                           # no hits (exit 1)

• Read-through, nothing executed: all 177 added lines of the 13 changed instruction files.
  • No new script, template or other non-.md file; no URL; no frontmatter hooks:; no render-time shell.
  • No concealed Unicode (tag-block, zero-width or bidi) anywhere in the v0.3.0 tree.
  • No conditional or "unattended-only" instructions.
  • allowed-tools grows only by Trinity's own ask_operator / get_my_ask (the ask contract refresh).
  • catalog.yaml is byte-identical between the tags.
• update-dashboard declares automation: autonomous with Bash and runs bash: recipes from the agent's own template.yaml metrics: entries. That is not a privilege escalation, but once scheduled it is an unattended recurring command channel.

Note to the release owner

DigitalOcean/AWS marketplace images seed v0.3.0 only once rebuilt from the 1.0 backend image (packer/digitalocean/scripts/01-provision.sh and packer/aws/trinity.pkr.hcl bake the images for one TRINITY_IMAGE_TAG, set from the build's image_tag variable). An image built from an earlier tag still seeds v0.2.0.

Follow-ups (not in this PR)

• docs: metric_read_service.py comment claims every bundled template ships /update-dashboard #3290: comment-only. The EMPTY_METRIC_MESSAGE comment in metric_read_service.py claims every bundled template ships /update-dashboard.
• docs: per-source skill-source sync docstring says it re-injects; only the full sync does #3291: the per-source skill-source sync docstring says it re-injects; only the full sync does.
• ent#529: existing installs follow the platform pin on upgrade.

Test plan

• pytest unit/test_2545_skill_source_pin.py unit/test_2550_annotated_tag_pin.py unit/test_ent237_skill_source_env_packaging.py unit/test_ent237_skill_sources.py unit/test_2763_skills_url_normalized_match.py unit/test_2338_journey_catalog.py: 185 passed at the branch tip (test_2338 reads the registry).
• Teeth, on a scratch copy at the tip. Config back to v0.2.0 turns the floor test and both parity tests red. The user doc alone at v0.2.0 turns only the user-doc test red. A second v0.3.0 phrase in the doc turns it red with the "exactly one" message. .env.example alone at v0.2.0 turns only its parity test red.
• tests/lint_sys_modules.py and tests/lint_root_test_placement.py are both OK.
• Proofs A and B above, with their controls on unmodified dev.
• CI: the full backend unit suite and the remaining checks. They were not run locally by design: this PR changes no image, compose file or base image.
• Optional manual check: a fresh stack shows the default source at v0.3.0 in Settings. Sync all twice keeps it green, and the Library then lists 38 skills including update-dashboard.

Fixes #3123

[AndriiPasternak31]

@vybe: this PR pins fresh 1.0 installs to trinity-skills v0.3.0. That release adds update-dashboard; the peeled commit is 7b2aa266. The PR is not waiting on you.

If you want a newer tag cut before the 1.0 release (2026-10-12), tell me the tag and I'll move it here. For example, main is 4 commits past v0.3.0, and the role pack in Abilityai/trinity-skills#2 is open. Moving it is:

• a one-line default change, plus .env.example and the doc line;
• a re-run of the sync proof;
• the same upstream diff review.

No test edit is needed, because the guard is a floor.

[dolho]

/review Report

Branch: AndriiPasternak31/issue-3123 → dev (merge-base a72271d9c)
Files Changed: 7 (+108/-27)
Scope: CLEAN
Plan Completion: 3 done / 0 partial / 0 not done / 1 changed / 0 unverifiable (#3123 acceptance criteria)

Upstream pin verification

• git ls-remote https://github.com/abilityai/trinity-skills: refs/tags/v0.3.0 exists as an annotated tag 9119c0d7, peeled to commit 7b2aa266d6cf. This matches the SHA in the PR's proofs, and the existing annotated-tag peel (bug(skills): a tag-pinned source is refused as moved on every sync after the first when the tag is annotated #2550) handles it.
• In a fresh bare clone, skills/update-dashboard/SKILL.md is present at v0.3.0. skills/ has 38 entries at v0.3.0 (41 at v0.2.0). git diff --stat v0.2.0 v0.3.0 -- ':!*.md' shows 8 files changed with 726 deletions and no additions, and the diff adds no URL lines. These match the supply-chain summary in the PR body.

Plan completion (#3123)

• AC1 DONE: src/backend/config.py:542 now defaults to "v0.3.0". The seed note is covered by test_seed_note_reports_the_configured_ref.
• AC2 DONE: the tag resolves, update-dashboard is present, and there are 38 skills (verified independently above). The PR body also includes end-to-end sync proofs.
• AC3 CHANGED: the AC asked for compose files to be updated too. I confirmed none of the compose files carries a value: docker-compose*.yml only pass TRINITY_DEFAULT_SKILL_SOURCE_REF through by name. .env.example and the user doc are updated. The remaining v0.2.0 mentions are building-agents.md ("v0.2.0 and later", still true), the historical whats-new/v0.9.5.md, and history rows. All of them are correct as written.
• AC4 DONE: the release-note line is in the PR body.

Execution coverage (Step 2.5)

changed symbol / test file	executed by	live consumer	verdict
config.DEFAULT_SKILL_SOURCE_REF	test_default_pin_is_at_least_the_floor_release, test_seed_note_reports_the_configured_ref	the fresh-install seed of the default skill source	✅ executed
.env.example / user-doc pin parity (test_env_example_documents_the_same_default, test_user_doc_states_the_same_default)	the tests themselves	CI (docs-vs-config parity)	🛡 guard (source-text by design; it parses SOURCE so a shell override cannot leak in)
tests/registry.json entry	unit/test_2338_journey_catalog.py (51 passed locally)	the test registry / journey catalog	✅ executed

Mutation: on a scratch copy with config.py reverted to "v0.2.0", the floor test, the .env.example parity test and the user-doc parity test all go red (3 failed). The tests have teeth.

Tests run locally: test_2545_skill_source_pin.py, test_2550_annotated_tag_pin.py and test_ent237_skill_source_env_packaging.py (26 passed), plus test_2338_journey_catalog.py (51 passed). test_ent237_skill_sources.py did not finish in my local environment, apparently because it was waiting on local services. The PR's CI pytest (head, seed 12345) job ran the full backend unit suite and it is green.

Critical Findings (block merge)

None.

Informational Findings (review required)

[I1] Docs: step 4 of the upgrade procedure is hard to follow (Confidence: 7/10)
File: docs/user-docs/automation/skills-and-playbooks.md (step 4, "Sync the whole library")
Issue: The step is accurate. I checked it against the code: only POST /api/skills/library/sync spawns run_fleet_reinject, it does so only on commit_changed with auto-reinject on, and PUT resets the sync status to never (db/skill_sources.py::update_source). But it packs four conditional cases into one paragraph, including a nested "unless another source also moved" aside.
Suggestion: Optionally split the "a per-source Sync already ran" recovery case into its own sub-bullet. This is not blocking.

[I2] Supply chain: update-dashboard is an autonomous Bash-capable playbook (Confidence: 6/10)
Issue: As the PR body already notes, update-dashboard declares automation: autonomous with Bash and runs commands taken from the agent's own template.yaml metrics: entries. A fresh install now has it in the Library. It reaches an agent only through explicit assignment, so this is not an escalation. Still, it becomes an unattended recurring command channel once someone schedules it.
Suggestion: No change needed in this PR. It may be worth one line in the release notes.

Clean Categories

• SQL & data safety: no DB, schema or migration changes. The seed path and update_source are unchanged.
• Race conditions: no runtime code changed beyond a string default.
• Auth boundaries: no endpoint changes. The doc correctly describes GET/PUT /api/skills/sources as admin-only and human-only (require_admin + reject_agent_principal, routers/skills.py).
• Credential exposure: none. The doc uses placeholders (<tag>, {id}).
• Enterprise disclosure in public docs: the added doc lines cover only the OSS skills catalog and its public API. Nothing touches private modules or gating.
• Enum/value completeness: there is no new constant. The other v0.2.0 mentions were checked and are correct (see AC3).
• Documentation staleness: the feature-flow history row, footer and index row are all updated.

Summary

• Critical: 0 (none found)
• Informational: 2 (optional)
• Scope: clean. The diff covers exactly the pin bump, its parity guards, the user doc and the feature-flow rows.

🤖 Generated with Claude Code

[dolho]

Approved — /review found no blocking findings; see review comment above.