You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a developer who has landed a small fix, I want the command to resolve my reference and the exact commit range before it writes anything, so that a fix is never recorded against the wrong commits or in a place the lane does not support.
Acceptance Criteria
Given a reference written as 123, #123, or acme/web-app#123, when the command resolves it, then a bare reference resolves against the home repository, a qualified reference resolves against the named repository, and the command determines whether the number is an issue or a pull request.
Given a reference that resolves to an issue carrying the repository's declared epic classification, when the command runs, then it stops, names /nxs.epic as the lane to use, and writes nothing.
Given.nexus/tmp/epic-<n>/ already exists for the same number, when the command runs, then it stops and writes nothing.
Given the command is run inside a member repository of a workspace, when it starts, then it stops with a diagnostic naming the qualified-reference form to run from the hub, and writes nothing.
Given the reference is a pull request that has not been merged, when the command resolves the range, then it stops and writes nothing.
Given the reference is an issue with exactly one merged closing pull request, when the command resolves the range, then it takes the range from that pull request.
Given a --range <base>..<head> argument, when the command resolves the range, then it uses those commits verbatim and does not prompt for a range.
Given a reference to an issue with no merged closing pull request, or with more than one, and no --range argument, when the command resolves the range, then it asks the developer for the range and never falls back to a guessed default such as the previous commit.
Given a resolved range whose head commit is not an ancestor of the trunk, when the command checks it, then the command stops and writes nothing.
Given any of the resolution paths above, when the range is recorded, thenbase and head are full commit SHAs, never a branch name and never HEAD.
Notes
Provenance is always the reference the developer named. The command never substitutes a pull request for the issue, or an issue for the pull request, even when it took the range from that pull request.
Refusing an epic and refusing a colliding entry directory are both guards against one silent, expensive failure: a fix entry shadowing an epic's materialization.
The trunk-ancestry rule is what keeps the entry drainable later. Recording a fix against work that has not landed guarantees the entry fails the drain's merge precondition and trains the operator to waive it.
This story resolves and refuses. It writes no files: #267 does that.
As a developer who has landed a small fix, I want the command to resolve my reference and the exact commit range before it writes anything, so that a fix is never recorded against the wrong commits or in a place the lane does not support.
Acceptance Criteria
123,#123, oracme/web-app#123, when the command resolves it, then a bare reference resolves against the home repository, a qualified reference resolves against the named repository, and the command determines whether the number is an issue or a pull request./nxs.epicas the lane to use, and writes nothing..nexus/tmp/epic-<n>/already exists for the same number, when the command runs, then it stops and writes nothing.--range <base>..<head>argument, when the command resolves the range, then it uses those commits verbatim and does not prompt for a range.--rangeargument, when the command resolves the range, then it asks the developer for the range and never falls back to a guessed default such as the previous commit.headcommit is not an ancestor of the trunk, when the command checks it, then the command stops and writes nothing.baseandheadare full commit SHAs, never a branch name and neverHEAD.Notes
Provenance is always the reference the developer named. The command never substitutes a pull request for the issue, or an issue for the pull request, even when it took the range from that pull request.
Refusing an epic and refusing a colliding entry directory are both guards against one silent, expensive failure: a fix entry shadowing an epic's materialization.
The trunk-ancestry rule is what keeps the entry drainable later. Recording a fix against work that has not landed guarantees the entry fails the drain's merge precondition and trains the operator to waive it.
This story resolves and refuses. It writes no files: #267 does that.
story_type: system · size: M