@enrichlayer/el-linear 1.44.1 → 1.44.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -99,6 +99,38 @@ el-linear issues read DEV-123 --format json 2>&1 | python3 -c "import json,sys;
|
|
|
99
99
|
|
|
100
100
|
`--body` is mutually exclusive with `--field` / `--sections` / `--with` (those extract named parts or extend the JSON envelope; `--body` is the whole thing as text).
|
|
101
101
|
|
|
102
|
+
#### Citing an issue's stated rationale: `--body` or `--field`, never `--format summary`
|
|
103
|
+
|
|
104
|
+
**`--format summary` truncates the description.** That is correct for scanning a board and wrong the moment you quote, cite, or reason from what an issue *says*. A research pass once read an issue with `--format summary`, saw a truncated description, and published the opposite of the design position that issue states outright — the fix was one command with a different flag, run twenty minutes too late.
|
|
105
|
+
|
|
106
|
+
So: the moment a claim is about an issue's **stated rationale** — what a decision claimed at the time, why an approach was chosen, what a spec requires — read `--body` (or `--field <section>` for one section) and quote from that.
|
|
107
|
+
|
|
108
|
+
```bash
|
|
109
|
+
# ✅ Reasoning from what the issue actually says
|
|
110
|
+
el-linear issues read DEV-123 --body 2>&1
|
|
111
|
+
el-linear issues read DEV-123 --field "Why we need this" 2>&1
|
|
112
|
+
|
|
113
|
+
# ❌ Citing a summary — the description you are quoting may be cut off
|
|
114
|
+
el-linear issues read DEV-123 --format summary 2>&1
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
The scope is narrow and worth stating precisely: an issue body is a weak source for *system behavior* — it records what someone intended, not what the code does — but it is the **authoritative** artifact for what a decision claimed at the time. Use it for the second, not the first.
|
|
118
|
+
|
|
119
|
+
#### An umbrella's status is not delivery evidence
|
|
120
|
+
|
|
121
|
+
A parent or umbrella issue's own status says nothing reliable about whether the work shipped. Read its children and slices, then read the artifact.
|
|
122
|
+
|
|
123
|
+
```bash
|
|
124
|
+
el-linear issues related DEV-100 --format summary 2>&1
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
Neither direction is safe on its own:
|
|
128
|
+
|
|
129
|
+
- **Canceled does not mean abandoned.** An umbrella is routinely closed as bookkeeping after its slices land — one was reported as "abandoned" in a research document while all six of its children were Done and the code was in production.
|
|
130
|
+
- **Done children do not prove delivery either.** A child can be a duplicate, a rename, or an administrative closure.
|
|
131
|
+
|
|
132
|
+
The tracker is a lead. The **merged MR or the deployed code** is the evidence — go look at it before writing "shipped" or "abandoned".
|
|
133
|
+
|
|
102
134
|
### Comment reads and full comment bodies
|
|
103
135
|
|
|
104
136
|
When you need a specific comment, or the full text of a long comment, use the
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@enrichlayer/el-linear",
|
|
3
|
-
"version": "1.44.
|
|
3
|
+
"version": "1.44.2",
|
|
4
4
|
"description": "A pragmatic CLI for Linear.app — deterministic team/label/member resolution, structured issue validation, configurable term enforcement, and a GraphQL escape hatch.",
|
|
5
5
|
"main": "dist/main.js",
|
|
6
6
|
"types": "dist/main.d.ts",
|