Skip to content

[feat] Make all distributed resources pushable with project and role namespaces #1101

Closed

Description

@jeff-r2026

Problem

TeamAI can pull namespaced resources, but teamai push is inconsistent:

  • skills, rules, agents: full push and namespace placement
  • env: pushable, but no automatic namespace placement
  • docs, hooks, MCP, models, claudemd, wiki: no common push path
  • learnings: uses contribute and only supports projects

This makes distribution one-way for several resource types.

Proposed Solution

Every team resource that TeamAI can pull should also be pushable through teamai push, using the existing PR or direct-push workflow.

All resource types should support:

teamai push --project checkout
teamai push --role frontend

The resource should be written to its matching namespace:

  • skills/<ns>/
  • rules/<ns>/ and claudemd/<ns>/
  • agents/<ns>/
  • docs/<ns>/
  • env/<ns>/env.yaml
  • hooks/<ns>/hooks.yaml
  • mcp/<ns>/mcp.yaml
  • models/<ns>/models.yaml
  • namespaced learnings and wiki sources

Push must update the team-repo source, not reverse-engineer merged Agent settings. Personal configuration and generated machine-local files must never be included.

Acceptance Criteria

  • Every pull-distributed resource has a push path.
  • --project resolves the resource’s namespace from manifest/projects.yaml.
  • --role targets a namespace allowed by manifest/roles.yaml.
  • Missing or ambiguous mappings fail instead of falling back to the shared root.
  • Existing PR update and direct-push behavior works for every resource type.
  • Pull and push use the same namespace rules.

Activity

  1. SaulMoro commented on Oct 13, 2026

    @SaulMoro
    Collaborator

    Could workflows/, prompts/ and scorers/ be part of this? Pull distributes them (#818, #1076), and today teamai push doesn't stage them.

  2. jeff-r2026 commented on Oct 14, 2026

    @jeff-r2026
    CollaboratorAuthor

    3. Could workflows/, prompts/ and scorers/ be part of this? Pull distributes them (#818, #1076), and today teamai push doesn't stage them.

    Yes. Include workflows/, prompts/, and scorers/ in this issue. Pull distributes them (#818, #1076), and teamai push should stage them the same way as the other resources, including --project and --role:

    • workflows/<ns>/
    • prompts/<ns>/
    • scorers/<ns>/
  3. SaulMoro commented on Oct 14, 2026

    @SaulMoro
    Collaborator

    On the pull side, syncWorkflowDefinitions reads only workflows/*.yaml at the root, so a workflow pushed to workflows/<ns>/ would never become runnable. One of this issue's acceptance criteria is that pull and push use the same namespace rules, so pull could read workflows/<ns>/, prompts/<ns>/ and scorers/<ns>/ here too, with the rule in namespace-resolver.ts.

  4. SaulMoro commented on Oct 14, 2026

    @SaulMoro
    Collaborator

    Notes from #1078 (#1129) for workflows under namespaces:

    • References resolve only by name against the validated cache. This covers workflow: review-and-fix in a step, and the cache keeps one definition per name (workflows/cache/<name>.json). Once the sync applies the namespace rule (a namespace item replaces the root item of its name; one name in two active namespaces is a conflict) before writing the cache, references follow it with no engine change.
    • A namespace conflict should leave that name with no runnable version. Do not keep an older winner. Pull diagnostics that carry a code already drop the cached copy that way.
    • prompt_file is resolved and cached into the definition at sync, including inside inline workflows. prompts/<ns>/ resolution belongs in that same place.
    • A cross-file pull check validates references, recursion, with keys, and reads of child outputs and ends per file. It has to run against the resolved set (after namespace resolution), not the raw directory listing.

    The engine rules that span files are in docs/dev/workflow-engine.md, added by #1129.

  5. legend91019 commented on Oct 19, 2026

    @legend91019
    Contributor

    Hello! I would like to claim this issue and implement support for pushing all distributed resources with project and role namespaces:

    1. Extend PlaceableType and NAMESPACE_AXIS (src/push-namespaces.ts):
      • Support all pull-distributed resource types: \skills,
        ules, \�gents, \docs, \env, \hooks, \mcp, \models, \claudemd, \learnings, plus \workflows, \prompts, and \scorers\ per the accepted discussion.
      • Resolve matching namespace axes from \manifest/projects.yaml\ and \manifest/roles.yaml.
    2. Namespace Placement on Push (\src/push.ts, \src/team-push.ts):
      • Support --project \ and --role \ across all resource types, placing files into their matching <resource>//\ directory (e.g., \env//env.yaml, \hooks//hooks.yaml, \mcp//mcp.yaml, \models//models.yaml, \workflows//, \prompts//, \scorers//).
      • Fail fast on missing or ambiguous mappings without falling back to the shared root.
    3. Pull-side Namespace Alignment (\src/namespace-resolver.ts, \src/sync.ts):
      • Ensure pull reads and validates namespaced workflows/prompts/scorers, enforcing the rule that a namespace item overrides a root item with identical name and conflicts drop invalid versions.
    4. Test Coverage:
      • Comprehensive unit and E2E regression tests for all resource types with --project\ and --role.
  6. SaulMoro commented on Oct 19, 2026

    @SaulMoro
    Collaborator

    Thanks for picking this up, @legend91019! The plan looks great.

    A couple of quick notes before you jump in:

    • Entry points: Pull coordination lives in src/pull.ts, and workflow sync/validation is in src/workflow/cache.ts (syncWorkflowDefinitions — there isn't a src/sync.ts).
    • Scope boundaries: Ensure teamai push respects scope isolation (workspace, user, self) so user-global or machine-local configs are never staged to team namespaces.
    • Workflow cache: A namespace conflict should drop that workflow from the runnable cache rather than keeping a stale version.

    Looking forward to the PR! Let us know if you hit any questions along the way.

  7. legend91019 commented on Oct 19, 2026

    @legend91019
    Contributor

    OK, thank you

  8. SaulMoro commented on Oct 19, 2026

    @SaulMoro
    Collaborator

    @legend91019 If you saw my earlier unedited comment mentioning learnings, ignore that part. Learnings should support --project and --role namespaces just like the other resources.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requestquestionFurther information is requested

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions