boost-skill-cli 1.2.170__tar.gz → 1.2.172__tar.gz

{boost_skill_cli-1.2.170 → boost_skill_cli-1.2.172}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.170
+Version: 1.2.172
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

{boost_skill_cli-1.2.170 → boost_skill_cli-1.2.172}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.2.170'
-__version_tuple__ = version_tuple = (1, 2, 170)
+__version__ = version = '1.2.172'
+__version_tuple__ = version_tuple = (1, 2, 172)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.170 → boost_skill_cli-1.2.172}/boost_cli/core/scopes.py

@@ -146,8 +146,40 @@ def owned_by(entries: dict, base) -> dict:
     if base is None:
         return {}
     want = os.path.realpath(base)
-    return {n: e for n, e in entries.items()
-            if e.get("scope") == SCOPE_PROJECT and _claims(e.get("base"), want)}
+    return {n: e for n, e in entries.items() if _owns(e, want)}
+
+
+def owns(entry: dict, base) -> bool:
+    """Does one user-lock entry belong to the project rooted at ``base``?
+
+    The single-entry form of :func:`owned_by`, and the same predicate rather
+    than a second opinion about it — ``list --local`` decides what a repo has
+    with the filter, and ``uninstall --local`` decides what it may remove with
+    this, so the two cannot disagree about one row.
+
+    **Both halves are load bearing, and the ``scope`` half defends a shape
+    boost's own install path does not write.** ``_install_rule`` and
+    ``_install_workflow`` emit ``scope`` and ``base`` in one dict, so the two
+    agree on every row an install produces. Two things read a row back and do
+    not: a hand-edited lock — the project lock is a *committed* file — and
+    ``update``/``reinstall``, which rebuild the install from
+    ``lk.get("scope", "user")`` and ``lk.get("base")`` *independently*
+    (``commands/pkg.py``), so a row carrying a ``base`` and no ``scope`` comes
+    back as user scope with the base intact. Dropping the ``scope`` test would
+    hand ``--local`` that row, which lives in the user's own config.
+
+    ``False`` for ``base is None`` — a caller standing outside any project
+    owns nothing — which is answered before ``realpath``, since resolving
+    ``None`` is a TypeError rather than an answer.
+    """
+    if base is None:
+        return False
+    return _owns(entry, os.path.realpath(base))
+
+
+def _owns(entry: dict, want: str) -> bool:
+    """:func:`owns` over an already-resolved ``want``, for the bulk filter."""
+    return entry.get("scope") == SCOPE_PROJECT and _claims(entry.get("base"), want)
 
 
 def _claims(recorded, want: str) -> bool:
@@ -160,13 +192,38 @@ def _claims(recorded, want: str) -> bool:
     against whatever directory the user happens to be standing in, so `"."`
     would make one entry belong to every repo at once.
     """
-    if not recorded or not isinstance(recorded, str | os.PathLike):
-        return False
-    if not os.path.isabs(recorded):
+    if not names_a_directory(recorded):
         return False
     return os.path.realpath(recorded) == want
 
 
+def names_a_directory(recorded) -> bool:
+    """Is a recorded ``base`` a claim on *some* directory at all?
+
+    The half of :func:`_claims` that needs no directory to compare against,
+    split out because one caller has none to offer: ``store`` decides whether
+    a removal result may *name* the repo it came from, where the question is
+    only whether the lock recorded a directory. Sharing the predicate is the
+    point — a base this rejects is one no project claims, so a result that
+    named it would print a repo that owns nothing.
+
+    The three clauses are **ordered, not independent**. ``isabs`` raises
+    ``TypeError: expected str, bytes or os.PathLike object, not dict`` on a
+    hand-edited lock's ``{"base": {}}``, so the ``isinstance`` test has to
+    come first and is what makes the last one safe to call at all. ``bool``
+    first is for reading, not for filtering: ``isabs("")`` is already False,
+    so the empty case would be caught anyway, and saying so up front is
+    cheaper than making the reader work it out.
+
+    What it rejects that a plain truthiness check does not is therefore two
+    things: a *truthy* non-string, and a *relative* path — which ``realpath``
+    would resolve against wherever the user happens to be standing, making
+    one entry belong to whichever repo is read from.
+    """
+    return (bool(recorded) and isinstance(recorded, str | os.PathLike)
+            and os.path.isabs(recorded))
+
+
 def check_scope(scope: str) -> str:
     """Return ``scope`` if it is one boost knows, else raise BoostError."""
     if scope not in SCOPES:

{boost_skill_cli-1.2.170 → boost_skill_cli-1.2.172}/boost_cli/core/store.py

@@ -1327,6 +1327,83 @@ def _install_project_skill(entry: dict, force: bool = False,
     return res
 
 
+def project_materialized(name: str, base) -> tuple[str, dict] | None:
+    """The user-lock rule or workflow row ``base``'s project owns — or None.
+
+    The two kinds a project lock cannot hold, looked up where they actually
+    live. Ownership is :func:`scopes.owns`, the same predicate ``list --local``
+    filters with, so the command that shows a row and the command that removes
+    it cannot disagree about whose it is.
+
+    **Ownership is tested before the name is resolved anywhere else.**
+    ``lockfile.find_any`` would be the obvious lookup and is the wrong one
+    here: it answers with the first *section* that holds the name, so a
+    user-scope skill called ``x`` outranks a project rule called ``x`` that
+    this repo owns, and ``--local`` would refuse to remove the row it can see
+    in ``list --local``. Rules before workflows only to fix an order; a name
+    in both sections is already ambiguous for bare ``uninstall``, which
+    resolves it the same way.
+
+    No ``base is None`` short-circuit, deliberately: :func:`scopes.owns`
+    answers ``False`` for it, so a guard here would be a branch no input can
+    reach — a falsification pass deleted one and every test still passed,
+    which is the definition of a line that is not doing anything. The cost of
+    leaving it out is two dict lookups on a path that then returns None.
+    """
+    for kind, get in (("rule", lockfile.get_rule),
+                      ("workflow", lockfile.get_workflow)):
+        row = get(name)
+        if row and scopes.owns(row, base):
+            return kind, row
+    return None
+
+
+def _not_in_this_project(name: str) -> BoostError:
+    """``uninstall --local``'s refusal, worded from where the item really is.
+
+    One sentence covered three states. It is **true** in all three — a rule
+    in the user's own config really is not installed in this project — and
+    useless in two, because it reports the one fact the reader already has
+    and withholds the one they need. Its hint sends them to ``boost list
+    --local``, which correctly shows nothing, so the message and the remedy
+    agree with each other and not with the machine. Each branch now names the
+    scope it found and the command that removes it from there, because the
+    item *is* removable and only the flag naming where it lives was not.
+
+    **No ``base`` parameter**, though the caller has one resolved. Every
+    branch is decided by :func:`lockfile.find_any`, which searches the user
+    lock as a whole and answers with the first *section* holding the name.
+    That is wider than what ``--local`` just rejected:
+    :func:`project_materialized` put ``scopes.owns`` only to the rules and
+    workflows sections, so a row this reports can be a **skill** no ownership
+    test has seen. Which is right for a message whose whole job is to say
+    where the item is *instead* — the row's own ``scope`` decides the wording,
+    and a user-scope skill is named as one. A parameter nothing reads is one
+    no test can pin — a mutation of it is unkillable by construction — so it
+    is not taken.
+    """
+    found = lockfile.find_any(name)
+    if found is not None:
+        kind, row = found
+        if row.get("scope") == scopes.SCOPE_PROJECT:
+            # Owned by some other checkout — `owns` already said not this one.
+            # The recorded base is named: it is the user's own lock, and a
+            # reader who cannot see which repo has it cannot act on this.
+            return BoostError(
+                "%s is a %s installed in %s, not in this project"
+                % (name, kind, row.get("base") or "another project"),
+                hint="remove it from there, or with `boost uninstall %s`"
+                     % name)
+        return BoostError(
+            "%s is a %s installed at user scope, not in this project" % (name, kind),
+            hint="remove it with `boost uninstall %s` (no --local)" % name)
+    # Genuinely absent. Byte-identical to what this raised before — the one
+    # state where naming where the item is instead is no help, because it is
+    # nowhere.
+    return BoostError("%s is not installed in this project" % name,
+                      hint="see what is with `boost list --local`")
+
+
 def project_skill_targets(base, name: str) -> set[Path]:
     """Every path a project install of ``name`` could legally have written.
 
@@ -1427,12 +1504,35 @@ def uninstall_project(name: str, base=None) -> dict:
     redirect as easily as a doctored path, so keeping it would be the same
     denial of service by another route. ``uninstall`` has no ``--json``, so
     the warning lines are the whole signal a caller gets.
+
+    **A rule or workflow gets none of those guards, and that is correct.**
+    A project lock holds a ``skills`` key and nothing else, so an
+    ``install --local`` of the other two kinds materializes into the repo but
+    records itself in the *user* lock tagged ``scope``/``base``. Everything
+    above exists because the project lock is a **committed** file that anyone
+    with merge rights can edit — a path out of it is input. The user lock is
+    not committed; it is the same file bare ``boost uninstall`` has always
+    read, and :func:`_uninstall_rule` / :func:`_uninstall_workflow` are the
+    same functions it has always called. So the fall-through adds no path
+    boost could not already be asked to delete, and re-deriving a legal set
+    for it would be ceremony over a threat that is not there.
+
+    What ``--local`` does is **narrow** eligibility, never widen it:
+    :func:`scopes.owns` admits only a row this repo claims, so a user-scope
+    rule and another checkout's rule both stay put. Before this,
+    ``list --local`` printed the rule and ``uninstall --local`` answered "not
+    installed in this project" — so the flag that performed the install could
+    not undo it, and said something false while refusing.
     """
     resolved_base = _resolve_base(scopes.SCOPE_PROJECT, base)
     entry = projectlock.get_skill(resolved_base, name) if resolved_base else None
     if not entry:
-        raise BoostError("%s is not installed in this project" % name,
-                        hint="see what is with `boost list --local`")
+        owned = project_materialized(name, resolved_base)
+        if owned is not None:
+            owned_kind, owned_entry = owned
+            return (_uninstall_rule if owned_kind == "rule"
+                    else _uninstall_workflow)(name, owned_entry)
+        raise _not_in_this_project(name)
     removed: list[str] = []
     refused: list[str] = []
     redirected: list[str] = []
@@ -1912,8 +2012,8 @@ def _refused_removal(name: str, path: Path):
         raise _removal_refused(name, path) from None
 
 
-def _remove_all_or_nothing(name: str, plan: list[tuple[Path, str]]) -> None:
-    """Apply an uninstall's removals, or none of them.
+def _remove_all_or_nothing(name: str, plan: list[tuple[Path, str]]) -> int:
+    """Apply an uninstall's removals, or none of them. Returns how many files.
 
     ``plan`` holds ``(path, new_text)`` for each file to change: ``""`` to
     delete it, other text to rewrite it. Every dir is checked before the
@@ -1924,6 +2024,18 @@ def _remove_all_or_nothing(name: str, plan: list[tuple[Path, str]]) -> None:
     Two rows can name one file (two enabled agents whose dirs resolve to one
     path), so the plan is de-duplicated on the resolved dir, not the resolved
     file, and a file already gone counts as removed.
+
+    The count is **files**, after that de-duplication, and never ``len(plan)``.
+    On the default agent table the two agree — a project rule measures five
+    rows at five distinct paths, because ``rules.CONTEXT_FILES`` gives each
+    context-file agent its own name there (``CLAUDE.local.md``,
+    ``GEMINI.md``, ``AGENTS.md``) and Cursor and Windsurf take a rules dir
+    each. They diverge on exactly what the de-duplication is for: two agents
+    configured at one dir, or a dotdir that is a symlink to another, which
+    ``path.parent.resolve()`` collapses. ``len(plan)`` would then tell the
+    user boost removed a file it removed once. The caller reports "removed
+    from <repo>" off this, the way :func:`uninstall_project` reports it off
+    paths that came off disk rather than off the agent list.
     """
     once: dict[Path, tuple[Path, str]] = {}
     for path, text in plan:
@@ -1937,6 +2049,7 @@ def _remove_all_or_nothing(name: str, plan: list[tuple[Path, str]]) -> None:
                 util.atomic_write_text(path, text)
             else:
                 path.unlink(missing_ok=True)
+    return len(once)
 
 
 def _present(path: Path) -> bool:
@@ -1977,10 +2090,10 @@ def _uninstall_rule(name: str, rule: dict) -> dict:
                 plan.append((path, ""))
         if m.get("agent"):
             removed.append(m["agent"])
-    _remove_all_or_nothing(name, plan)
+    gone = _remove_all_or_nothing(name, plan)
     lockfile.remove_rule(name)
     journal.log("uninstall", name)
-    return {"name": name, "unlinked": removed, "entry": rule, "kind": "rule"}
+    return _materialized_result(name, removed, rule, "rule", gone)
 
 
 def quarantine_materialized(kind: str, name: str, entry: dict) -> list[str]:
@@ -2234,10 +2347,53 @@ def _uninstall_workflow(name: str, workflow: dict) -> dict:
                 plan.append((path, ""))
         if m.get("agent"):
             removed.append(m["agent"])
-    _remove_all_or_nothing(name, plan)
+    gone = _remove_all_or_nothing(name, plan)
     lockfile.remove_workflow(name)
     journal.log("uninstall", name)
-    return {"name": name, "unlinked": removed, "entry": workflow, "kind": "workflow"}
+    return _materialized_result(name, removed, workflow, "workflow", gone)
+
+
+def _materialized_result(name: str, removed: list[str], entry: dict,
+                         kind: str, gone: int) -> dict:
+    """The uninstall result for a rule or workflow, scope carried through.
+
+    ``scope`` and ``base`` come off the lock entry rather than off how the
+    caller got here, because both callers reach the same row: bare
+    ``boost uninstall`` and ``boost uninstall --local`` remove one
+    ``--local`` rule by the same two functions. Reporting the repo only on
+    the flagged path would make the same removal describe itself two ways.
+
+    A user-scope entry has neither key and gets neither, so ``cmd_uninstall``
+    reads ``scope`` as absent and prints exactly what it printed before.
+
+    **Both keys or neither**, and a ``base`` that names a directory is
+    required for it. A lock is a file on disk, so a row can say
+    ``scope: project`` and record no usable directory —
+    :func:`scopes.owned_by` already treats that shape as real and drops it,
+    because a row that claims no directory is claimed by none. Carrying
+    ``scope`` without one would put the key in the dict with that value,
+    where the caller's ``info.get("base", "this repo")`` default can never
+    fire: ``paths.tilde`` is ``str(p)``, so ``None`` prints as *removed from
+    None* and a hand-edited ``{"base": {}}`` prints as *removed from {}* —
+    over a removal that worked.
+
+    The test is :func:`scopes.names_a_directory`, the same one ownership is
+    decided with, rather than a truthiness check beside it. Measured, the two
+    agree on every *falsy* base — ``None``, ``""``, ``{}``, ``0`` are dropped
+    either way — and differ on exactly two things, both of which a lock can
+    hold and an install cannot write: a **truthy** non-string, which would
+    print *removed from 17*, and a **relative** path, which names a different
+    repo depending on where the reader is standing. The relative case is the
+    one that carries the difference in practice, so it is the one the test
+    turns on.
+    """
+    res = {"name": name, "unlinked": removed, "entry": entry, "kind": kind,
+           "removed_count": gone}
+    if (entry.get("scope") == scopes.SCOPE_PROJECT
+            and scopes.names_a_directory(entry.get("base"))):
+        res["scope"] = scopes.SCOPE_PROJECT
+        res["base"] = entry["base"]
+    return res
 
 
 def install_from_path(src_dir: Path, name: str | None = None,

{boost_skill_cli-1.2.170 → boost_skill_cli-1.2.172}/boost_skill_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.170
+Version: 1.2.172
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

boost_skill_cli-1.2.172/docs/roadmap/items/uninstall-local-cannot-remove-a-rule-or-workflow-list-local-shows.md

@@ -0,0 +1,80 @@
+---
+id: uninstall-local-cannot-remove-a-rule-or-workflow-list-local-shows
+board: code
+section: dx
+status: shipped
+category: CLI · Bug
+complexity: S
+impact: Med
+wow: 3
+note: shipped — the fall-through, plus a refusal that names where the item really is
+order: 355
+owner: loop/uninstall-local-rules
+pr: 1021
+title: "<code>uninstall --local</code> cannot remove a rule or workflow that <code>list --local</code> shows"
+---
+<code>boost install &lt;rule&gt; --local</code> works, and since PR #998 <code>boost list
+--local</code> prints the rule it installed. <code>boost uninstall &lt;rule&gt; --local</code>
+then exits 1 with &ldquo;<code>&lt;rule&gt; is not installed in this project</code>&rdquo; and the
+hint <code>see what is with `boost list --local`</code> &middot; which is the command that just
+showed it. There is no way to undo the install through the scope flag that performed it.
+
+The cause is one line: <code>store.uninstall_project</code> (store.py:1291) reads
+<code>projectlock.get_skill</code> and nothing else, because a project lock holds a
+<code>skills</code> key alone. A rule or workflow installed <code>--local</code> is recorded in
+the <em>user</em> lock tagged <code>scope: project</code> with a <code>base</code>, so the
+project lock genuinely has no row &middot; but the user lock does, and bare <code>boost
+uninstall &lt;rule&gt;</code> finds it and works. So the item is removable; only the flag that
+names where it lives is not.
+
+Two candidate fixes, and the choice is a design decision rather than a typo. Either
+<code>uninstall_project</code> falls through to the user lock for a row whose <code>scope</code>
+is project and whose <code>base</code> is this repo (<code>scopes.owned_by</code> already answers
+exactly that question, and is what <code>list --local</code> now uses), or <code>--local</code>
+refuses a non-skill with a message that says <em>use bare <code>uninstall</code></em> rather
+than claiming the thing is not installed. The first is what a reader expects; the second is one
+line. Either way the current message is wrong on its facts, which is the part that must not
+survive. Found while verifying
+<code>audit-project-scope-seams-uninstall-verify-list-info-reinstall-dis</code>.
+
+<b>Shipped: the fall-through, and the message fixed anyway.</b> Reproduced first — a real
+<code>install house-style --local</code> materializes five rows (<code>CLAUDE.local.md</code>,
+<code>GEMINI.md</code>, <code>AGENTS.md</code>, <code>.cursor/rules/*.mdc</code>,
+<code>.windsurf/rules/*.md</code>), <code>list --local --kind rule</code> prints it, and
+<code>uninstall --local</code> exited 1 saying it was not installed.
+<code>store.project_materialized</code> now looks the name up in the rule and workflow sections
+of the user lock and admits a row only when <code>scopes.owns</code> says this repo claims it;
+<code>uninstall_project</code> hands that row to the same
+<code>_uninstall_rule</code>/<code>_uninstall_workflow</code> bare <code>uninstall</code> has
+always called.
+
+<b>Why those functions get none of the guards the skill path has.</b> Everything in
+<code>uninstall_project</code>'s derived-legal-set machinery exists because the <em>project</em>
+lock is a committed file — a path out of it is input. The user lock is not committed, and is the
+same file bare <code>boost uninstall</code> already reads, so the fall-through adds no path boost
+could not already be asked to delete. What <code>--local</code> does is <b>narrow</b>
+eligibility, never widen it.
+
+<b>Three details that were not free.</b>
+<code>scopes.owns</code> is the single-entry form of the filter <code>list --local</code> uses,
+not a second opinion about it — the two commands disagreeing about whose a row is <em>is</em> this
+bug.
+Ownership is asked of the rule and workflow sections <em>directly</em>, never through
+<code>lockfile.find_any</code>, which answers with the first section holding the name: a
+user-scope skill called <code>x</code> would outrank a project rule called <code>x</code> this
+repo owns, and <code>--local</code> would go on refusing the row <code>list --local</code> shows.
+And <code>_remove_all_or_nothing</code> now returns a count of <em>files</em> after its
+de-duplication rather than rows. The two agree on the default agent table &mdash; five rows at
+five distinct paths, since <code>rules.CONTEXT_FILES</code> gives each context-file agent its
+own name at project scope &mdash; and diverge on what the de-duplication exists for: two agents
+configured at one dir, or a dotdir symlinked to another. Counting rows there would report a file
+removed twice.
+
+<b>The message was useless in two of its three states</b>, which is not the same as wrong: a rule
+in the user&rsquo;s own config really is not installed in this project. It reported the one fact
+the reader already had and withheld the one they needed, and its hint sent them to
+<code>list --local</code>, which correctly shows nothing. Both branches now name where the item
+really is: a user-scope rule says so and points at bare <code>uninstall</code>; a row owned by
+another checkout names that checkout, and both carry the command that removes it from there. The
+genuinely-absent branch is kept byte-identical &mdash; it is the one state where naming where the
+item is instead is no help, because it is nowhere.

{boost_skill_cli-1.2.170 → boost_skill_cli-1.2.172}/docs/roadmap.html

@@ -6551,38 +6551,14 @@ its own pass rather than a bolt-on inside this PR. Left <code>inflight</code> ra
       </article>
 
       <article class="cap rcard" id="uninstall-local-cannot-remove-a-rule-or-workflow-list-local-shows">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">CLI · Bug</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">CLI · Bug</span></div>
         <h3><code>uninstall --local</code> cannot remove a rule or workflow that <code>list --local</code> shows</h3>
-        <p><code>boost install &lt;rule&gt; --local</code> works, and since PR #998 <code>boost list
---local</code> prints the rule it installed. <code>boost uninstall &lt;rule&gt; --local</code>
-then exits 1 with &ldquo;<code>&lt;rule&gt; is not installed in this project</code>&rdquo; and the
-hint <code>see what is with `boost list --local`</code> &middot; which is the command that just
-showed it. There is no way to undo the install through the scope flag that performed it.
-
-The cause is one line: <code>store.uninstall_project</code> (store.py:1291) reads
-<code>projectlock.get_skill</code> and nothing else, because a project lock holds a
-<code>skills</code> key alone. A rule or workflow installed <code>--local</code> is recorded in
-the <em>user</em> lock tagged <code>scope: project</code> with a <code>base</code>, so the
-project lock genuinely has no row &middot; but the user lock does, and bare <code>boost
-uninstall &lt;rule&gt;</code> finds it and works. So the item is removable; only the flag that
-names where it lives is not.
-
-Two candidate fixes, and the choice is a design decision rather than a typo. Either
-<code>uninstall_project</code> falls through to the user lock for a row whose <code>scope</code>
-is project and whose <code>base</code> is this repo (<code>scopes.owned_by</code> already answers
-exactly that question, and is what <code>list --local</code> now uses), or <code>--local</code>
-refuses a non-skill with a message that says <em>use bare <code>uninstall</code></em> rather
-than claiming the thing is not installed. The first is what a reader expects; the second is one
-line. Either way the current message is wrong on its facts, which is the part that must not
-survive. A test wants a rule installed <code>--local</code>, asserted present in <code>list
---local</code>, then removed by <code>uninstall --local</code> with the context file checked for
-the stripped block. Found while verifying
-<code>audit-project-scope-seams-uninstall-verify-list-info-reinstall-dis</code>.</p>
-        <div class="meta">
-          <span class="m">Complexity <b>S</b></span>
-          <span class="m">Impact <b>Med</b></span>
-          <span class="m">Wow <b class="wow">★★★</b></span>
-          <span class="m">list --local prints the repo's rule; uninstall --local says it is not installed</span>
+        <p class="cardbody"><a class="writeup" href="https://github.com/jonnyeclectic/boost/blob/main/docs/roadmap/items/uninstall-local-cannot-remove-a-rule-or-workflow-list-local-shows.md">Write-up &middot; uninstall-local-cannot-remove-a-rule-or-workflow-list-local-shows.md</a></p>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">shipped — the fall-through, plus a refusal that names where the item really is</span>
         </div>
       </article>
       <!-- /ROADMAP:cards -->