← Story Solution E2e Multi overview

Agent Snapshot: story_solution_e2e_multi

• Context ID: story_solution_e2e_multi

Base cliPrompts

[1] ./agents/instructions/story_solution/affected_repos_multi_task_split.md

Affected Repositories — Multi-Task Splitting (opt-in)

This instruction extends the base affected_repos_flow.md output format. It is only included in SA agents that want to split the work inside a single repository into several independently trackable Sub-tasks (instead of exactly one Sub-task per repository). If this file is not in your cliPrompts, ignore it — keep emitting the plain per-repository schema.

When to split a repository into multiple tasks

Add a tasks array to a repository entry only when the work inside that one repository is naturally separable into pieces that can be developed, reviewed, and tested independently — for example:

• A schema/migration change vs. the business logic that consumes it.
• A backend API/entity change vs. a client-only follow-up in the same repo.
• Two unrelated modules/packages within a monorepo-style repository that don’t share files and could be picked up by different developers in parallel.

Do not split when:

• The pieces are small and tightly coupled (same class/file, same PR anyway).
• Splitting would only produce artificial “step 1 / step 2” tickets that must always be worked by the same person in the same sitting — that’s still one task, just phrase the reason as a short ordered list instead.
• There is genuinely only one repository‑scoped unit of work — most tickets should still end up with a plain single-task-per-repo entry.

When in doubt, prefer not splitting. Over-splitting creates Jira overhead (more tickets to triage, review, and close) without a real parallelization or tracking benefit.

Mandatory self-check before writing the final reason

A single “big” reason string is a smell, not automatically a valid single task. Before finalizing a repository entry, count the distinct new/changed classes, modules, endpoints, or components you are about to list for that repository (ignore config/wiring one-liners).

• 0–2 distinct items, or all items are in the same file/class: keep it as one task — write the plain reason.
• 3 or more distinct items in one repository: do not silently fold them into one reason sentence just because they ship for the same feature. Re-apply the split criteria above to each item individually. If at least two of them could realistically be reviewed/merged as separate PRs (even if all are needed before the feature works end-to-end), emit a tasks array — one task per independently reviewable item, with depends_on capturing the build order. Only keep it as a single task if you can state a concrete reason two of the items cannot be separated (e.g. they are the same class, or one is a one-line call inside the other).
• A shared theme (“all needed for the same new feature”) is not by itself a reason to keep items merged — features regularly span multiple independently reviewable pieces within one repository.

Schema

A repository entry MAY add a tasks array. When present, it takes precedence over the top-level reason for Sub-task creation (the top-level reason is still shown in the Affected Repositories table as a one-line rollup summary).

{
  "name": "repo-a",
  "reason": "One-line rollup summary shown in the table.",
  "depends_on": ["repo-z"],
  "tasks": [
    {
      "id": "schema",
      "title": "Add new table migration",
      "reason": "Migration + entity for the new table.",
      "depends_on": []
    },
    {
      "id": "processor",
      "title": "Implement OrderStatusProcessor",
      "reason": "Business logic consuming the new schema; depends on the migration landing first.",
      "depends_on": ["schema"]
    }
  ]
}

depends_on reference forms (task-level, only inside a tasks array)

• "schema" — another task’s id within the same repo.
• "repo-z:some-id" — a specific task in another repo (repo:id).
• "repo-z" — a bare repo name — depends on all of that repo’s tasks (or its single implicit task if that repo has no tasks array). Same meaning as the repo-level depends_on in the base schema.

Rules

• Every id must be unique within its repo’s tasks array (not globally — repo-a:schema and repo-b:schema can coexist).
• Do not repeat information between a task’s reason and its parent repo’s rollup reason — the rollup should read as a one-sentence summary of all the repo’s tasks combined, not a duplicate of the first task.
• If a repository entry has no tasks array, it is still processed as exactly one Sub-task, identical to the base (non-multi) flow — this keeps the schema backward compatible with affected_repos_flow.md.