linersh 1.0.2 → 1.0.3

package/README.md

@@ -54,6 +54,11 @@ corpus with your configured local Claude or Codex runner, then run Create
 Operating Layer. Because `HOME`, the npm cache, and `LINER_DIR` all point inside
 `$tmp`, cleanup is just `rm -rf "$tmp"`.
 
+For release testing on a machine that may already have Liner installed, first
+run the hard-reset smoke commands in [PUBLISH-CHECKLIST.md](PUBLISH-CHECKLIST.md).
+That removes global `linersh`, npx execution caches, Liner config/cache, and
+Playwright Chromium before the external-user `npx linersh@<version>` test.
+
 ## Run Locally
 
 From the repo root:
@@ -98,6 +103,10 @@ Notes:
 - Release packaging is verified with `npm run acceptance:go -- release-smoke`,
   which packs a local platform package plus the main `linersh` package and
   installs both into a clean consumer project.
+- Public release tarballs are generated by
+  `scripts/release-tarballs.sh --version <version>` from the repo root. The
+  script writes the local tarball folder, checksums, and the exact npm publish
+  command block Arturo should run.
 
 ## Useful Environment Variables
 

package/bin/liner.js

@@ -355,7 +355,8 @@ function tryResolveCliCommand() {
 }
 
 function tryResolveHeadlessRunnerScript() {
-  return join(packageRoot, "dist", "agents", "headless-runner.js");
+  const candidate = join(packageRoot, "dist", "agents", "headless-runner.js");
+  return existsSync(candidate) ? candidate : null;
 }
 
 function printVersion() {

package/cli-update-docs/curator-notes.md

@@ -72,13 +72,14 @@ In both modes, notes are required. A source without a note doesn't ship.
 
 ## Worked examples
 
-> TODO: Insert three to five worked examples from the Cowork CLI/TUI synthesis. Each should show all three things landed. Look for notes in the Cowork material that are concrete about role, location of value, and limitations — not vague praise.
->
-> Suggested examples to pull:
-> - A "watch first" foundational note (likely on a Van Slyck talk or clig.dev)
-> - A note with specific time-coding on a video ("the section starting at 14:30")
-> - A trim note that explicitly says what to skip ("Skip the OpenStack-specific noise")
-> - A "contested counterpoint" note that names the source it disagrees with
-> - A note that names a temporal limitation ("dated on X, durable on Y")
-
-> TODO: Insert one or two examples of bad notes for contrast. Pull the original AI-drafted notes from OpenClaw if they're available — those are the canonical "this is a useful resource" generic notes that Cowork rewrote.
+Good notes:
+
+- "Watch first for the operating model: the middle section names the workflow constraint this corpus adopts. Dated on tool names, durable on the interaction principle."
+- "Use as the counterpoint to the default stance. Strong on risks and failure modes; do not treat it as the corpus's main recommendation."
+- "Skim the setup and use the worked example section. It shows the output bar, but the implementation details are platform-specific."
+
+Bad notes:
+
+- "Useful overview of the topic."
+- "Highly recommended resource."
+- "Good background reading."

package/cli-update-docs/quality-check-tests.md

@@ -90,8 +90,6 @@ If yes, keep the better one and cut the other. Volume is not a virtue. Five exce
 
 Redundancy is different from coverage. Two sources covering the same topic from different angles or with different evidence is coverage, not redundancy. The test is whether the AI would generate meaningfully different output with both vs. with only one. If not, redundant.
 
-> TODO: Insert a worked example from the Cowork synthesis where two sources were collapsed because of redundancy. The Van Slyck talk appearing in transcripts 02 and 03 is a known case — same talk uploaded twice. Show how the redundancy was named and resolved.
-
 ---
 
 ## Test 2 — The coverage test
@@ -107,8 +105,6 @@ A mixtape that silently omits a major area is worse than one that says explicitl
 
 If a section has sources but they're all rated 2 or 3, that's a weak-coverage signal — the section is technically populated but the sources aren't load-bearing. Either find stronger sources or note the weakness.
 
-> TODO: Insert a worked example. If the Cowork synthesis had a section that needed reinforcement after first-pass evaluation, show the coverage check that surfaced it and how the gap was addressed.
-
 ---
 
 ## Test 3 — The disagreement test
@@ -123,8 +119,6 @@ If the topic is genuinely uncontested — the W3C HTML spec, for example, isn't
 
 **The test in action:** identify the strongest claim in the corpus. Search for "[claim] critique" or "[claim] is wrong" or "alternative to [claim]." If you find a credible critique you haven't included, you've found your dissenting source. Add it.
 
-> TODO: Insert a worked example from CLI/TUI research. The corpus probably had a contested-question moment — possibly around whether CLIs should follow Unix conventions strictly vs. break them deliberately, or around accessibility being assumed-by-default vs. explicitly designed-for. Surface the actual disagreement and how it was handled.
-
 ---
 
 ## Test 4 — The framing-gap test
@@ -189,8 +183,6 @@ The earlier loose version of this test failed quietly in practice. A real sessio
 
 If the framing gap is real, accept the cost of going back. Phase 2 is cheap relative to shipping a mixtape with a hole in it.
 
-> TODO: Insert the canonical worked example from the Cowork synthesis. OpenClaw's initial 50-source list was anchored in "CLI/TUI implementation" framing and missed "the entire wizard/form-design tradition (Form Design Patterns, NN/g articles, Tidwell, Cooper)." Cowork ran the framing-gap test, named the missing tradition, added 43 net-new sources, and reframed the corpus. This is the textbook framing-gap-test rescue. Pull the specific moment the gap was identified and the specific sources added.
-
 ---
 
 ## Test 5 — Source-kind balance
@@ -431,8 +423,6 @@ user_can_add:
 skip_note: What remains weaker if the user skips for now.
 ```
 
-> TODO: Insert a sample `working/04-quality-checks.md` from the Cowork synthesis. The full structure with each test, the finding, and the resulting action is the most useful worked example in this file.
-
 ---
 
 ## A note on fresh attention

package/cli-update-docs/source-finding-tactics.md

@@ -16,8 +16,6 @@ This tactic is the single highest-leverage move for discovering primary document
 
 **How to apply:** Open the most credible source you have. Scan the references, footnotes, or "further reading" section. Note every source that's cited *and* recurs in another credible source's references. Recurrence across multiple credible sources is the signal — it's how you find the references nobody links anymore.
 
-> TODO: Insert worked example from the Cowork CLI/TUI synthesis. Look for a moment in the research where citation-chasing surfaced a canonical source that didn't show up in any initial keyword search. Form Design Patterns by Adam Silver is a candidate — it's cited across multiple Phase 1 sources but didn't surface from "CLI wizard design" searches.
-
 ---
 
 ## 2. Reverse-engineer experts' reading lists
@@ -30,8 +28,6 @@ Are.na deserves a specific note: it's a network designed for visual and textual
 
 **How to apply:** Find three to five experts in the domain. Search each one's name plus "reading list" or "syllabus" or "references." Catalog what they recommend. Cross-reference with the candidates already on your long-list — overlaps are strong signal; uniques are leads.
 
-> TODO: Insert worked example from the Cowork CLI/TUI synthesis. Look for a tactical mention of an expert reading list that surfaced relevant work. If none exists, this section can use an example from a different domain — the methodology generalizes.
-
 ---
 
 ## 3. Mine course syllabi
@@ -49,8 +45,6 @@ University courses, bootcamp curricula, and serious online courses have already
 
 Course syllabi skew toward foundations. They're best for the early-section knowledge-map buckets. Recent practitioner work is rarely on them.
 
-> TODO: Insert worked example. If no syllabus surfaced in the CLI/TUI research, note this and use a hypothetical that's specific enough to be useful.
-
 ---
 
 ## 4. Find who experts cite
@@ -61,8 +55,6 @@ This tactic is structurally similar to citation-chasing (#1), but starts from pe
 
 **How to apply:** Identify three to five practitioners credible in the domain. Open their most recent significant work. Note the sources they cite. Open the sources cited by two or more practitioners. Those are your high-priority candidates.
 
-> TODO: Insert worked example from CLI/TUI research. Carolyn Van Slyck, Aanand Prasad (clig.dev), Will McGugan (Textualize), and Amanda Pinsker (GitHub CLI) are candidates whose citation patterns could be traced.
-
 ---
 
 ## 5. Conference proceedings
@@ -73,8 +65,6 @@ Going through three years of a specific conference is more efficient than topic-
 
 Conference talks vary widely in density. The same talk reposted across multiple conferences is one signal of substance. Talks from speakers who are also cited by other practitioners (tactic #4) are another.
 
-> TODO: Insert worked example. The CLI/TUI corpus has multiple Van Slyck talks across GopherCon and other venues — a real example of how conference-proceeding mining surfaced both her work and what to keep when the same talk appears at multiple conferences.
-
 ---
 
 ## 6. Ask the AI to find gaps, not sources
@@ -87,8 +77,6 @@ AI is bad at recall — at remembering and surfacing sources you don't know abou
 
 This tactic is structurally related to the framing-gap test in Phase 5, but earlier and lower-stakes. Doing it in Phase 2 is cheaper than discovering the gap in Phase 5 and having to backtrack.
 
-> TODO: Insert worked example from the Cowork synthesis. The Cowork run discovered that OpenClaw's initial 50-source list missed "the entire wizard/form-design tradition (Form Design Patterns, NN/g articles, Tidwell, Cooper)" — this is the canonical example of gap-finding working. Pull the specific moment where the gap was named and how it changed the candidate pool.
-
 ---
 
 ## 7. Search for the core action and the curator anchors

package/cli-update-docs/source-quality-hierarchy.md

@@ -171,8 +171,6 @@ Drop unless the source encodes a genuinely transferable pattern. A Ratatui tutor
 
 A source flagged as "low-value" during candidate discovery (Phase 2) sometimes turns out to be the only one that addresses a specific gap once you've actually read every candidate. If a low-priority source uniquely covers a knowledge-map section that would otherwise be empty or thin, rescue it. Mark the decision and the rationale clearly.
 
-> TODO: Insert worked example from the Cowork CLI/TUI synthesis. The canonical example is the Caligula segment inside transcript #34 "some cool Linux programs you've never seen" — OpenClaw flagged it as lower-value, Cowork rescued it as "the closest direct precedent in your whole corpus." This is the textbook rescue move. Pull the specific decision and the rationale used.
-
 ### Author overrepresentation
 
 Three of five sources in a section are by the same author. This narrows perspective and reduces the AI's ability to synthesize across views. Keep the single strongest piece by that author; replace the others with sources by different practitioners. The exception: if the author has genuinely written the canonical work in multiple sub-areas, and no other practitioner has equivalent work, keeping multiple pieces is justified — but you should be able to defend it.
@@ -209,5 +207,3 @@ candidates:
 ```
 
 For dropped sources, the rationale should name *why* dropped — "duplicates Source 4," "shallow listicle," "AI-generated," "off-topic relative to JTBD." Generic "low quality" is not useful. Be specific.
-
-> TODO: Insert two or three worked evaluation entries pulled from the Cowork synthesis — one keep with rating 5, one trim with rating 3, one drop with a specific rationale. These are the highest-leverage examples in the file.

package/cli-update-docs/synthesis-guidance.md

@@ -134,9 +134,13 @@ If the synthesis names source numbers ("Source 1 argues..."), it's probably synt
 
 ## Worked examples
 
-> TODO: Insert two worked synthesis excerpts from the Cowork CLI/TUI synthesis. The full Cowork document is the longest worked example available — pull the opening framing paragraphs as one example, and a contested-question or distinction paragraph as another.
+Good synthesis shape:
 
-> TODO: Insert one example of synthesis-as-recap (bad) for contrast. Either invent one against the CLI/TUI material or pull an earlier draft if one exists. The bad example should make the difference between "describing sources" and "framing a domain" obvious at a glance.
+> This corpus treats onboarding as a trust-building sequence, not as a checklist. The useful question is not "which screens does the user see?" but "what does each step prove before asking for the next commitment?" Sources disagree on how much explanation belongs up front, but they converge on one rule: every prompt should reduce uncertainty before it increases work.
+
+Bad synthesis-as-recap shape:
+
+> Source 1 explains onboarding screens. Source 2 covers empty states. Source 3 discusses progressive disclosure. Together, these sources show that onboarding is important.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "linersh",
-  "version": "1.0.2",
+  "version": "1.0.3",
   "description": "Liner — npm shim, Go TUI launcher, and headless methodology runner.",
   "type": "module",
   "license": "MIT",