Why merged code looks like yours
Your product did not start from nothing. It started as a copy of another repository and keeps receiving its changes by merge: sign-in, the admin panel, subscriptions, teams. That code sits in your own folders, and nothing in its path says it came from somewhere else.
So a defect in it looks like your defect. It is not. Fixing it in your product leaves the original broken, every other product built on it keeps the same defect, and the next merge from above overwrites your fix.
That is why the planning and build steps ask, before changing anything, whether the code is your project's to change at all.
How ownership is decided
By the history of the lines that are wrong, never by what the code is about. For each line, the run looks at the change that last touched it and whether that change came in through the repository your product descends from. A defect that sounds like sign-in can still be a line your product wrote, and one file often holds lines of both.
When the defect is something missing rather than a wrong line — a link nobody added, a state nobody handles — the same question is asked of the code that would have to change to add it.
The chain can be longer than one. The repository your product descends from may descend from another. The run follows the change upward to the repository that wrote it, because a fix made one step too low leaves the real owner broken and comes back with the next merge. Which repository your product descends from is read from your repository's own remote settings, not guessed from a branch name.
When a repository in that chain cannot be reached from your machine, the run says which ones it checked and which it could not, and names no owner rather than a wrong one.
A package works the same way. One your project downloads belongs to its own repository. One kept inside your project, even when it looks installed, is yours.
What a run does about it
It does not edit the other repository. It works only in the project it was started in. Two commands go further on purpose: /design-catalog can fix weblabor-base or weblabor-teams when you say yes, and /coordinate writes the plan in each repository its goal needs and brings each finished change down with a merge.
It hands you the request to take there: what is wrong, on which screen or flow, in which states, and what the correct behavior would be — written so somebody who never saw your conversation can act on it. It also says that your project is waiting on it, and for what, so it is not treated upstream as an isolated defect. Take that request to /plan-prompt in the repository it names.
The rest of your work carries on. Only what genuinely depends on the fix waits. When planning finds the split, what belongs to your project is planned and saved as usual, and the part that waits is saved as its own plan. When the build step finds it halfway, the points that depend on the fix are blocked, everything else is built and committed, and you are pointed to /plan-prompt in your project to make the plan wait for the fix instead of sitting blocked.
How the waiting plan clears itself
The waiting plan names the behavior it is waiting for — never a commit, a branch or a version — and plans only what your project builds. Its row stays at Ready to run.
Every time the queue is read, it looks for that behavior in your code. Until the fix has been merged into your project, the plan is skipped and named as still waiting. Once the behavior is there, it is built like any other plan. Nobody has to come back and change a status.
A local patch would satisfy the plan just as well, and the work can go ahead either way. It does not close the request upstream: that stays open until the other repository fixes it, because the next merge from above would remove the patch.
Next
- Run the queue with /next — how a waiting plan is picked up once the fix arrives.
- Planning before building — what
/plan-promptdoes with the request in the other repository. - How a task travels — where in a run this question is asked.