This is a focused, well-reasoned docs clarification. The old "Deployment" entry in terminology.md conflated the act of deploying with the artifact it produces, which was genuinely confusing — the new text separates them cleanly: a deployment is the action, a version is the artifact, and a failed deployment produces no version. The new "Rollback" entry fills a real gap, and the cross-links between all three entries ([deployment](#deployment), [version](#version), [rollback](#rollback)) are all valid anchors.
The parallel update to deployment.md line 21 is consistent: the old sentence implied every deployment creates a version ID; the new sentence correctly distinguishes successful from failed deployments.
One small pre-existing tension worth flagging (not introduced by this PR): the miren app history example table in deployment.md shows a VERSION column with an ID-formatted string even for the ✗ (failed) row. Under the new terminology a failed deployment has no version, so that column label is a little misleading for failed rows. Since this PR didn't introduce that table and its meaning is pre-existing, it's not a blocker here — but it'd be worth a follow-up to either relabel that column "DEPLOYMENT ID" or add a note that the ID shown for failed rows is the deployment ID, not a version ID.
Ready to merge as-is.
VERSION column header here applies to all rows, including the ✗ (failed) one (line 148 shows myapp-vCVmuoeQCzjoNN9hGsu14c with a ✗ status). A reader who just read the new Deployment/Version definitions will wonder what that column means for a failed row. Worth a small follow-up to relabel it DEPLOYMENT or ID, or add a note that for failed deployments this is the deployment record ID rather than a version ID. (Pre-existing issue, not introduced by this PR — just surfaces more sharply now.)Verdict: ready
{
"owner": "mirendev",
"repo": "runtime",
"number": 982,
"verdict": "ready",
"event": "approve",
"summary": "This is a focused, well-reasoned docs clarification. The old \"Deployment\" entry in terminology.md conflated the act of deploying with the artifact it produces, which was genuinely confusing — the new text separates them cleanly: a deployment is the *action*, a version is the *artifact*, and a failed deployment produces no version. The new \"Rollback\" entry fills a real gap, and the cross-links between all three entries (`[deployment](#deployment)`, `[version](#version)`, `[rollback](#rollback)`) are all valid anchors.\n\nThe parallel update to `deployment.md` line 21 is consistent: the old sentence implied every deployment creates a version ID; the new sentence correctly distinguishes successful from failed deployments.\n\nOne small pre-existing tension worth flagging (not introduced by this PR): the `miren app history` example table in `deployment.md` shows a `VERSION` column with an ID-formatted string even for the `✗` (failed) row. Under the new terminology a failed deployment has no version, so that column label is a little misleading for failed rows. Since this PR didn't introduce that table and its meaning is pre-existing, it's not a blocker here — but it'd be worth a follow-up to either relabel that column \"DEPLOYMENT ID\" or add a note that the ID shown for failed rows is the deployment ID, not a version ID.\n\nReady to merge as-is.",
"comments": [
{
"path": "docs/docs/deployment.md",
"line": 122,
"side": "RIGHT",
"body": "Under the new terminology, a failed deployment produces no version — but the `VERSION` column header here applies to all rows, including the `✗` (failed) one (line 148 shows `myapp-vCVmuoeQCzjoNN9hGsu14c` with a `✗` status). A reader who just read the new Deployment/Version definitions will wonder what that column means for a failed row. Worth a small follow-up to relabel it `DEPLOYMENT` or `ID`, or add a note that for failed deployments this is the deployment record ID rather than a version ID. (Pre-existing issue, not introduced by this PR — just surfaces more sharply now.)"
}
],
"posted_to_pr": true
}