Repository navigation
feat(workflow): offer teamai-share-learnings only when share can run, and name workflows by their alias - #1568
Conversation
…rnings and teamai-share-session teamai-share-learnings shares one or several learnings after one approval, each linked to the session, then runs teamai-share-session, which publishes and scores the session. The friction reminder and describe follow the new names. Proof: default-workflows, share-learnings-run, session-share*, preflight tests.
…by its own name A workflow whose alias starts it gets workflow-<alias>; a name teamai ships a default under keeps that name (teamai-share-session), so people meet the name the team chose. A default's skill says it is teamai's default. pull offers no teamai-share-learnings skill while share is withheld (recall off or a read-only source), since its learning step runs share. Prune and uninstall also look at teamai-* directories, by the marker only. Proof: workflow-skills-discovery and uninstall tests.
…he legacy prune, and follow recall with it The legacy skill teamai-share-learnings and the skill pull now generates for the default workflow share a directory name. The legacy prune skips a directory that carries the generated marker, and recall enable/disable redeploy the workflow skills, so the share skill appears and goes with recall instead of waiting for the next pull. Proof: recall-toggle test (red: legacy prune warned and the skill stayed).
`teamai list workflows` prints `fix (review-and-fix) (team)` for a workflow whose alias starts it. The rule "the alias starts it" now lives in one place, startingAlias, which the generated skills use too. Proof: status-list and workflow-skills-discovery tests.
A run record carries the alias its workflow's definition had when the run started, and the Workflows page shows the alias first, with the workflow's name beside the run id, in the run table and the run's detail. Proof: dashboard-workflow-runs tests; the page in a browser (PR).
…ings The real-CLI run contributes two learnings after one approval, each on its own contribute pass and each recorded as an outcome of the shared session. Proof: npm run test:e2e -- src/__tests__/e2e/share-learnings-1388.test.ts
…ce of workflow-session-close Proof: npm run test:e2e for assigned-roles-1186, local-agent-teardown-915, source-ambiguous-foreign-claims, contribute-check.
…as the name people see Both languages of the workflow, knowledge, dashboard, scorers and sharing guides, the share/core/setup skills, the changelog entries of the unreleased defaults, and the engine notes. The doc workflow examples parse with parseWorkflow.
…hare is withheld, and require the teamai- prefix of every default
…ugh a hand-off to the dashboard
…e redeploy and learning tags each in one place
…n an alias conflict, and generated skill names in the workflow skill
… settling in either order
|
No confident findings in the specified PR diff. The PR description documents sufficient testing, including a real-CLI run after Review was read-only; I did not run, build, or install PR code. |
SaulMoro
left a comment
SaulMoro
left a comment
There was a problem hiding this comment.
This was generated by AI during triage.
@hz89Dev Thanks. With the built CLI, head against main:
- Recall gating works. With recall off (
sharing.recall.enabled: false,recallEnabled: falseorTEAMAI_RECALL_DISABLED=1), or with a read-only http source, pull writes onlyteamai-share-session, including when the team has its own copy ofteamai-share-learnings. Main writesworkflow-session-closein all of these cases. recall enable/disableadd and remove the skill at once.- Skill names follow the alias table, and
list workflowsshowsfix (review-and-fix) (team). Starting by alias or by name recordsalias: fix. - Two learnings in one run each reach
teamai-learnings, each linked to the session. - Upgrading is clean: an install pulled with main loses
workflow-session-closeon its first pull with this head.
tsc, lint and the changed tests (583) pass, 35 of those tests fail on main, and CI is green.
One thing blocks merge.
- [P1 blocking] A team
teamai-share-sessionwith other inputs breaks everyteamai-share-learningsrun. The defaultteamai-share-learningscallsteamai-share-sessionwith five inputs (session, source, publish, scorers, judge). The engine checks that the sub-workflow accepts them only when the step starts (src/workflow/engine.ts:563-565), so pull,list workflows, describe and start all accept the pair. To reproduce, add a teamteamai-share-session.yamlwithalias: wrap-up, the docs' own example, that declares onlysessionandsource. The Stop reminder still offersteamai-share-learnings, and both learnings are contributed. Then the run fails withinvalid_inputs: inputs.publish is not an input workflow "teamai-share-session" declares, and the team's wrap-up never runs. With no override, or with an override that declares all five inputs, the same run succeeds. Checking the fit when the tree loads (start/describe), or at pull, would catch it before the member's learnings are half shared. The docs should also say, in both languages, that a replacement must accept these inputs.
Optional:
- [P3 nit]
teamai list skills -vlabels the generatedteamai-share-learnings[builtin], because the name is still on the legacy built-in list, whileteamai-share-sessionshows[local-only].
The CI review reported no confident findings. The point above only shows once a run reaches the sub-workflow step.
This conflicts with #1379 in the workflow docs, src/dashboard/client.ts, src/dashboard/workflow-runs.ts and src/workflow/engine.ts.
…shared, while the team's teamai-share-session takes other inputs
… teamai-share-learnings included
|
[P1] A team
The check covers every [P3] Tests: full #1379: it is still open and |
The PR description documents sufficient testing: a real-CLI run after Review was read-only; I did not run, build, or install PR code. |
…e alias replaces the workflow it runs
|
Fixed in 3237ef7. The pull check now resolves the workflow a default runs the same way Your case, |
|
No confident new findings in the specified PR diff. The earlier [P2 non-blocking] alias-validation finding is resolved: default validation now resolves team workflows by name, then alias, with a regression test covering the reported case. The PR description documents sufficient testing, including real-CLI verification after Review was read-only and limited to the specified diff. I did not run, build, or install PR code. |
SaulMoro
left a comment
SaulMoro
left a comment
There was a problem hiding this comment.
This was generated by AI during triage.
@hz89Dev Thanks, the names case is fixed at 3237ef7f. With the built CLI and a team teamai-share-session (alias: wrap-up) that declares only session and source:
pullwarns once per missing input and writes noteamai-share-learnings.startand describe refuse withinvalid_inputsbefore any run exists.
With all five inputs declared, everything works. The alias case the CI review raised fails at f39a898b and passes here. The [workflow] label and the docs in both languages are in.
One case still gets through:
- [P1 blocking] The same five names, with a different type. A team
teamai-share-sessionthat declarespublishas astringpassespullwith no warning and starts. The run then fails atshare-sessionwithinputs.publish must be a string, after the learning step, so the team's wrap-up never runs. The load-time check compares input names only (src/workflow/cache.ts:527–532). For the shipped default's sub-workflow, comparing each passed input's declared schema with the packaged default's would close it. Look the packaged default up by the reference name: an alias replacement's own name iswrap-up.
Optional:
- [P3 nit] The docs write
/teamai-share-learningswith a leading slash (line 618, both languages). - [P3 nit] The comment at
src/workflow-skills.ts:35says more about the check's scope than it does.
Team-to-team workflows with a type mismatch also pass pull and fail at the child step. That is the same on main, so it is outside this PR.
Lint & Test on Node 24 ubuntu, the Windows job and the E2E shards are green. The macOS Lint & Test jobs were still running when I checked.
…replaces teamai-share-session takes one of its inputs as another type
|
[P1] The same five names, with a different type. Your reproduction,
Team-to-team workflows keep the name check only, as you scoped it. The docs and CHANGELOG now say the five inputs keep their types. [P3] I dropped the slash from New test in |
The earlier alias-validation finding is resolved, with regression coverage. The PR description documents sufficient testing: real-CLI verification after Review was read-only and limited to the specified diff; I did not run, build, or install PR code. |
SaulMoro
left a comment
SaulMoro
left a comment
There was a problem hiding this comment.
This was generated by AI during triage.
@hz89Dev Thanks, the type case is fixed at 5d58585a. With the built CLI, a team teamai-share-session that declares publish: string is refused, both under its own name and as the wrap-up alias replacement. So is the two-input case from the CI review. Correctly typed teams still work. Both nits are fixed.
One thing still blocks approval. It is the CI review's point from 23:06Z, which reproduces:
-
[P1 blocking] Enum order counts as a different type. A team
teamai-share-sessionwith the same five names and types, butjudgelisted asdriver | hereinstead ofhere | driver, is refused:pullwarns thatjudgeis "another type" and writes noteamai-share-learnings.- describe and
startfail withinvalid_inputs.
The check compares enums with
isDeepStrictEqual(src/workflow/cache.ts:562), which depends on order. The docs say "same types". Comparing enum values as sets, plus a test with a reordered enum, would close it.
Optional:
- [P3 nit] In
docs/guide/workflow.md(line 621), the sample under the type-case sentence shows the missing-input warning, not the type warning.
Lint & Test and the E2E shards were still running when I checked. The Windows job passed.
…ues, in any order
|
Fixed in 71fd928. Input types are now compared structurally ( |
…'s order does not count
|
Both points are fixed. [P1] Enum order. Fixed in 71fd928. Input types are compared structurally ( [P3] Docs sample. Fixed in 084b1b3. The sample on both pages now shows both warnings, the missing input and |
|
No confident new findings in the specified PR diff. The earlier alias-validation and enum-order findings are resolved, with regression tests covering both cases. The PR description documents sufficient testing: real-CLI verification after Review was read-only and limited to the specified diff. I did not run, build, or install PR code. |
SaulMoro
left a comment
SaulMoro
left a comment
There was a problem hiding this comment.
This was generated by AI during triage.
@hz89Dev Thanks, the enum-order case is fixed at 084b1b32. With the built CLI, a team teamai-share-session that declares judge: driver | here pulls with no warning, and a teamai-share-learnings run with it succeeds. publish: string and the two-input case are still refused, and the docs sample now shows the type line.
One thing left, small:
-
[P2 non-blocking] A duplicate enum value passes as the same type. With
judge: here | here,pullprints no warning, and so do describe andstart. A run with"judge":"driver"then fails atshare-sessionafter the learning step:inputs.judge must be one of here, here. At5d58585athe same file was refused before any run.sameType(src/workflow/cache.ts:559) compares the lengths and then checks one way, and the parser keeps duplicate values. A two-way check fixes it:- return right.type === 'enum' && left.values.length === right.values.length && left.values.every((value) => right.values.includes(value)); + return right.type === 'enum' && left.values.every((value) => right.values.includes(value)) && right.values.every((value) => left.values.includes(value));
A
here | herecase beside the reorder test would cover it.
Lint & Test and the E2E shards were still running at 084b1b32 when I checked; the Windows job passed. I'll approve once they are green.
…s not stand for a missing one
|
Fixed in d0e8177 with the two-way check you suggested. A new test beside the reorder one declares |
The earlier alias-validation and enum-order findings are resolved, with regression coverage. The PR description documents sufficient testing: real-CLI verification after Review was read-only and limited to the specified diff; I did not run, build, or install PR code. |
…aces teamai-share-learnings while share is withheld
|
Gate alias-based replacements: fixed in 3f341a5. The gate in |
|
No confident new findings in the specified PR diff. The earlier alias-validation, enum-order, and alias-gating findings are resolved, with regression tests covering all three cases. The PR description documents sufficient testing: real-CLI verification after Review was read-only and limited to the specified diff. I did not run, build, or install PR code. |
|
The Windows job failed on a timeout, not an assertion: |
SaulMoro
left a comment
SaulMoro
left a comment
There was a problem hiding this comment.
This was generated by AI during triage.
@hz89Dev Thanks. At 3f341a58 both remaining points are fixed: the enum check is two-way, with the here | here test, and the share gate now covers a team workflow whose alias is teamai-share-learnings, with a test for it. Approving.
CI at 3f341a58 was green when I approved.
Summary
With recall off,
teamai pullstill wrote theworkflow-session-closeskill. Its first step runsteamai skill get share, which recall withholds, so the skill sent the agent into a step that could not run. #1520 has not shipped yet (npm latest is 0.28.1), so this PR reshapes it before release: the default is split in two, and a workflow's alias becomes the name people see.Generated skill names:
alias: fix)workflow-fixteamai-share-sessionworkflow-<name>When the
teamai-share-learningsskill is written. Not while recall is off or the source is a read-only http source. This also applies to a team copy of it.teamai recall enable/disableadd or remove the skill immediately.Several learnings per run. One session can share several learnings, each contributed with
--session-id, so one session links to all of them.The alias is the name people see:
list workflowsshowsfix (review-and-fix) (team).startaccepts the name or the alias.Outcomes on the Workflow Runs page. The "Pull requests" column becomes Outcomes and lists both pull requests and the learnings a run shared. The run detail lists the learnings too.
Naming and cleanup rules:
teamai-; teamai fails to load a default that doesn't.workflow-*andteamai-*directories, and only touch ones that carry the generated-skill marker.teamai-share-learningsskill survives it.Stop-hook reminder. It now offers
teamai-share-learnings.A team
teamai-share-session, or a team workflow whose alias replaces it, must take the five inputsteamai-share-learningspasses it, with the same types. With other inputs, or one of another type:pullwarns once per input and writes noteamai-share-learningsskill.startand describe refuse withinvalid_inputsbefore any learning is shared.teamai skill get share.The check runs whenever a workflow's tree loads, so it covers every sub-workflow step, not only this pair.
teamai list skills -vlabels generated workflow skills[workflow]. This includesteamai-share-learnings, which used to show[builtin]because of its legacy name.Type of Change
session-closenever shipped in a release, so dropping it breaks nothing.Test Plan
npx tsc --noEmitpassesnpm run lintpassesnpx vitest runpasses: 18980 passed. Three tests timed out under load inworkflow-reconciliationandworkflow-settle-cost, two files this PR does not touch; both pass when run on their own (13/13).npm run test:e2e -- src/__tests__/e2e/share-learnings-1388.test.ts src/__tests__/e2e/assigned-roles-1186.test.ts src/__tests__/e2e/local-agent-teardown-915.test.ts: 20/20 passed. After the review fixes,share-learnings-1388andworkflow-session-1086passed 5/5; in the latter, the aliased workflow's skill is nowworkflow-ship. The share-learnings e2e shares two learnings from one session and checks both onteamai-learningsand as session outcomes.Real CLI, after
npm run build, with Claude and agitprovider (self mode). Recall starts off:A team
teamai-share-sessionwithalias: wrap-upand onlysessionandsource, then the same file with all five inputs:The same five names, with
publish: string:Codex, CodeBuddy, OpenCode and the
gitlab/githubproviders are left to CI.Workflow Runs page
The
teamai-share-learningsrow from alice is a synthetic run record pushed toteamai-reportsto show two learnings. The other rows are real runs from the CLI session above.Desktop, Outcomes column:
Desktop, alias first with the name under it:
Related Issues
Follows #1520 (for #1388).
Notes for Reviewers
share-sessionhasneeds: [], on purpose. The session is published and scored even when the person declines every learning, assession-closedid.recall enable/disabledon't add the skill to git exclude. Like the existingdeployRecallArtifacts, they write without a delivery recorder, since onlypullrecords git-exclude paths. The next pull reconciles them.map, so it can't list titles alone.teamai-prefix is not reserved. A team file with a default's name, or with an alias equal to it, replaces that default.