@stapel/listings-react 0.25.10 → 0.27.0

package/CHANGELOG.md

@@ -1,5 +1,264 @@
 # @stapel/listings-react
 
+## 0.27.0
+
+### Minor Changes
+
+- 630b418: **The reader's cluster can be in two places, and is one thing.**
+  `<ListingDetailPane actionsPlacement>` now takes a LIST (`["header", "bar"]`)
+  and a new `renderActionsBar` render prop is handed the cluster's MOUNT POINT,
+  not a copy of it: `<ListingActions>` is rendered once through a portal whose
+  container is moved between the two slots as a DOM node, so the component mounts
+  once, holds one `useFavoriteToggle`, and is literally the same element in both
+  placements. A container that wanted the two verbs beside the title AND in a
+  condensed top bar had to mount a second `<ListingActions>` of its own — two
+  hearts agreeing only after a refetch, and its own test ids so the pane's
+  `listings-detail-reader-actions` stayed single for anything counting it. That
+  second mount can go. Returning `null` from `renderActionsBar` hands the cluster
+  back home mid-write; asking for `"bar"` without the render prop changes
+  nothing at all, as does every existing single-placement mount.
+
+  **And `onTitleVisible` says when to ask for it.** An `IntersectionObserver` on
+  the pane's own title — never a scroll listener — reporting each crossing. The
+  same container watched that heading through the pane's published `data-testid`
+  and a `MutationObserver` (the title lands with the listing, not with the first
+  frame) for a boolean the pane already knew. Nothing is reported in an
+  environment with no `IntersectionObserver`: "this page cannot tell" is an
+  answer, and a fabricated `true` would wedge a host's bar open on the one arm
+  with no scrolling to close it.
+
+  **The gallery's shape is the host's, and saying so costs no `!important`.**
+  `<ListingDetailPane galleryLayout>` takes `"grid"` (default, the
+  element-width grid this pane has always drawn) or `"strip"` — a snap-scrolling
+  horizontal strip, one photograph visible with the next peeking. On a 390px
+  phone the grid resolves to ONE column, so a listing with three pictures pushes
+  its own title and price nearly three screens down. The pane also stops writing
+  `display` and the track INLINE: they are on `LISTINGS_GALLERY_CLASS` plus a
+  `data-gallery-layout` attribute now (`detailGalleryCss()`, exported), so a host
+  that wants a third shape at its own breakpoints needs a selector rather than
+  `!important` over a pair's own geometry. A live storefront was carrying exactly
+  that `!important`. What stays inline is what nobody overrides: the page's
+  responsive gutter (D418) and the `position: relative` the
+  `actionsPlacement="gallery"` overlay is pinned to.
+
+  **The takedown tab draws the SERVER's number (D407, second half).** Pinned to
+  stapel-listings **v0.22.4**, which adds `MyCountersResponse.blocked` beside
+  `active` / `archived` / `drafts`. The fourth tab was counted from its own
+  unpaged `?status=blocked` page — right up to a page and blind past one, and
+  only after that page had landed. It is the counter now: the tab appears with
+  `my/counters`, the badge is the whole set, and the page stays what it always
+  was underneath, the tab's rows. A deployment on a server older than 0.22.4
+  sends no `blocked` and degrades to the rows' length — never to a `0`, which is
+  the defect wearing the new field.
+
+## 0.26.0
+
+### Minor Changes
+
+- f5a7906: A card's spec line stops printing a caption where a value is expected, and stops
+  captioning two axes identically (D421).
+
+  Measured on a live feed (translated): **"HONOR · Model 90 · 256 GB"** — three
+  facts, and the middle one reads as a value that begins with the word "Model";
+  and **"5 fl. · 9 fl. · 54 m²"** — the floor a flat is on and the number of
+  floors in the building, one number and its unit each, twice, with nothing
+  saying which is which.
+
+  Neither is a defect in the server's `presentation`: it was right about each
+  element ALONE. What it cannot see is where the text is PUT. A badge strip gives
+  every element a chip border; a spec line joins them with `" · "`, so a space
+  inside one item is not punctuation and a shared unit is not a distinction.
+
+  - **`CardBadgeStyle`.** `cardBadgeText(row, locale, style)` and
+    `cardBadgeTexts(rows, locale, style)` take `"badge"` (the default — every
+    existing call keeps its bytes) or `"line"`. The `name_value` pair is joined
+    with a space in a chip, exactly as the 0.22 contract wrote it, and with a
+    **colon** in a line: `"Model: 90"`, which is the punctuation that says what
+    follows is the answer to this.
+  - **The collision pass.** Ambiguity is a property of the SET, so it is resolved
+    once in `cardBadgeTexts`: elements printed without a caption that share a unit
+    — or that print identical text — get their catalogue names back, in the
+    `name_value` shape the contract already defines (`"Floor: 5 fl. · Floors:
+9 fl."`, and in a chip strip `"Floor 5 fl."`). It refuses to act where it
+    would not help: a group whose names are missing, or that would wear one word
+    twice, is left as the server wrote it rather than captioned with noise.
+
+  `<CardBadges variant="line">` — the spec line under every card's title — passes
+  `"line"`; the badge strip is byte-identical.
+
+- f5a7906: The listing gallery's gutter is the page's own, per breakpoint (D418).
+
+  Measured on the live listing page: `getComputedStyle(gallery).gap` answered
+  **`12px` at 1280 and `12px` at 390**, and the gaps between neighbouring photos
+  were 12 on both — while the page around it declares 4px on a phone and 24px on
+  a desktop. Neither declared number was ever on screen: the grid painted a flat
+  `spacing[3]`, so its tiles sat closer together than the page edge on a desktop
+  and three times further apart than it on a phone.
+
+  `--stapel-page-gutter` is a responsive token role (`@stapel/tokens`: 4 / 8 / 24
+  by breakpoint, declared once with its own media arms), and the gap reads it as
+  a VAR rather than as a number picked in JS — a computed value is applied at
+  render, so a window resized between renders keeps the gutter it was drawn with,
+  where a var reflows. Written through `cssVar` so a renamed role fails to
+  compile instead of resolving to nothing, with the old flat step as the fallback
+  for a host that loads no token stylesheet. Exported as `DETAIL_GALLERY_GUTTER`
+  for a container laying out against the same edge.
+
+- f5a7906: A listing a moderator pulled has a tab, and a number (D407).
+
+  The desktop walk opened a cabinet holding one taken-down listing and read
+  three statements about it at once: the row itself, saying "taken down by a
+  moderator"; the counters over it, reading **"Active 0 · Drafts 0 ·
+  Archived 0"**; and the active tab's own empty state, saying nothing of the
+  seller's was live. The row was on the page, in no tab and in no number — and a
+  person reads the numbers. `blocked` is grouped by `my/counters` in none of the
+  three, so the pane fetched it separately and rendered it in a block above the
+  tab strip, which is exactly the half that was wrong: a row outside the tabs is
+  a row the counters do not describe.
+
+  **`removed` is the fourth tab.** `MY_LISTINGS_TABS` is the server's three plus
+  it; `MY_LISTINGS_COUNTED_TABS` and `countedTabOf()` are the three on their own,
+  for anything that has to line up with `MyCountersResponse`. Its rows are the
+  takedown read that already existed (`?status=blocked`, unpaged, running
+  whichever tab is open), so its **count is right while the seller is looking at
+  a different tab** — the state the defect was measured in. It is drawn only
+  where there is something in it, or where `?tab=removed` asks for it, and the
+  line above the tab strip stays as a LINE (`listings-mine-takedowns`, no rows),
+  so a takedown still cannot be missed without being printed twice on one screen.
+
+  Not folded into `archived`, which is the other shape this could take: that tab
+  reads the server's `archived` integer, which does not count takedowns, so the
+  badge would go on reading `0` for everyone not looking at it — and "I put this
+  away" and "a moderator took this down" are not one sentence.
+
+  **The gap this leaves, stated rather than papered over:** `my/counters` carries
+  three integers and no fourth, so the removed tab's number is the length of one
+  unpaged `?status=blocked` page. A seller with more takedowns than that page
+  holds would see the page and not the total, and there is no counter on the wire
+  to check it against.
+
+  `MyListingsTab` gains `"removed"`; `MyListingsSource` is deliberately **not**
+  widened — it stays typed `MyListingsCountedTab`, because the fourth tab never
+  goes through a host source and a source written before this release has no
+  answer for a tab it has not heard of.
+
+- 510531b: A listing can be sent to somebody, and the heart is where a thumb already is.
+
+  The owner's finding on the live storefront (2026-09-06): **no «Поделиться»
+  anywhere in the product.** Not a badly placed share control, not one behind a
+  menu — none. The only way to send somebody an offer was the address bar, which
+  on a phone is the hardest thing on the screen to reach and which carries the
+  SERP query the visitor arrived from, the page anchor and whatever tracking
+  parameters came with them. Beside that, the reference measurement (§23): our
+  listing page drew a 152px "Save to favourites" button with a word in it at
+  every width, where the reference classified draws a 44×44 glyph and puts a
+  share glyph next to it.
+
+  **`<ShareAction>` and `useShare`.** Two arms, and the DEVICE picks. Where
+  `navigator.share` exists — every phone, almost no desktop — a press opens the
+  platform's own sheet with `{title, text, url}`: the person's apps, in their
+  order, including the ones we have never heard of. Where it does not, it opens a
+  menu: copy the link, Telegram, WhatsApp, VK. The menu is a `Popover` and that
+  is a documented exception to `stapel/no-tooltip-in-skin` rather than a hole —
+  click-only trigger (a thumb and a cursor use one gesture), a live enabled
+  anchor, and four CONTROLS in the overlay rather than a sentence somebody has to
+  hover to read. Every outbound link is `target="_blank"` with **both** halves of
+  `rel="noopener noreferrer"`, and every field is percent-encoded: a seller's
+  title contains `&` and `#` in the wild, and a raw one silently truncates the
+  URL the recipient receives at the first `&`.
+
+  **The URL is the host's, never the address bar.** `shareUrl` is used verbatim
+  (a path resolved against the document base); `window.location.href` is the
+  fallback for a host that supplied nothing, which is honest for a bare mount and
+  wrong for an app that has a canonical route.
+
+  **`<ListingActions>` — the reader's two verbs as one cluster.** Icon-only, 44px
+  each, at the trailing edge of the title row (`actionsPlacement="gallery"` pins
+  them over the photographs instead; `"buy-box"` is the escape hatch for a host
+  laid out around the old position). The owner of a listing keeps the share
+  button and loses the heart: you do not favourite your own listing, and sending
+  somebody your own listing is the first thing a seller does. `actions` now takes
+  either the node it always took OR `{ share: false }` / `{ favorite: false }` —
+  a plain object was never a legal `ReactNode`, so the two arms cannot be
+  confused.
+
+  **The card heart moved onto the photograph.** `<ListingCard>` and
+  `<ListingSerpCard>` join `<ListingFeedCard>`, which has drawn it there since it
+  existed: trailing top corner — the one corner of the strip that is free, since
+  the dots own the bottom centre and the "3 of 16" counter the bottom trailing —
+  outside every anchor, and stopping a press from reaching the card behind it.
+  Only the blocked visitor's REASON stayed in its row under the card, because a
+  sentence has nowhere to live on top of a picture, and that row is now drawn
+  only when there is something to put in it rather than as an empty strip of
+  padding under every card on a page. The SERP card's action rail keeps whatever
+  the container put in it and nothing else.
+
+  **Two hit-target tiers, stated once as a class contract.** 44px for the page's
+  controls at every width; 36px for a card's with a cursor and 44px with a thumb
+  — the reference's own desktop measurement, and the glyph does not change size
+  in either tier. `actionRow.ts` holds both, so "how big is this control" has one
+  answer in this package instead of one per surface (the SERP heart was 32px, the
+  feed heart 40).
+
+  **Confirmations are said twice, and briefly.** "Link copied" stands inside the
+  open menu AND goes out as a two-second toast; the heart's fill is the state and
+  "Added to favourites" / "Removed from favourites" is the acknowledgement a
+  glyph in the corner of a photograph cannot carry. The message seam is antd's
+  own — `App.useApp().message` where the host mounted `<App>`, antd's static
+  `message` otherwise — so there is no new dependency, no host wiring, and no
+  confirmation that exists only in a toast a person may not have been looking at.
+
+  Ten i18n keys in en/ru/es. Measured with dependencies held constant: `index`
+  15.27 → 15.99 KB (ceiling 16 → 17; the old one was hit EXACTLY, and a budget
+  passed by rounding is a budget the next sentence fails), `default` 25.34 →
+  27.56 KB (ceiling 26 → 29).
+
+### Patch Changes
+
+- f5a7906: A card's photo strip says how many photographs there are.
+
+  The mobile walk drove a real touch swipe across a feed card and watched the
+  indicator move correctly — `data-active` hopping from the first dot to the
+  second, the strip settling where the finger left it — and then recorded what
+  was missing beside it: **no counter of any kind**, where the reference
+  classified leads with "1 of 16".
+
+  Dots say WHERE in a strip a reader is and stop being countable at about five.
+  Only a number says how deep it goes, and on a phone — where the strip is one
+  photograph wide and the next one is off-screen — that number is the only thing
+  saying a swipe is worth making. `<ListingPhotoStrip>` (the strip every card
+  surface in this pair draws, `<ListingSerpCard>` included) now carries one:
+  `<testId>-counter`, bottom-trailing so it never argues with the dots'
+  bottom-centre, moving with a swipe, a hover scrub and a native scroll alike
+  because it reads the same `active` the dots do.
+
+  `aria-live="polite"`: a finger scrolling the strip changes the picture with
+  nothing else to report it. `pointer-events: none`, which is load-bearing rather
+  than tidy — the box under it owns the scrub and the swipe, and a pill that
+  swallowed a pointer would make one corner of every photograph dead to both. A
+  one-photograph strip gets no counter, exactly as it gets no dots and no peek.
+
+  The pill's scrim is a fixed translucent black with white text, and it is the
+  one place in this package where a theme role would be wrong: it sits on an
+  arbitrary PHOTOGRAPH, which is neither light nor dark.
+
+- f5a7906: The delete dialog stops promising the archive to a listing already in it.
+
+  Measured on the phone walk, deleting from the **Archive** tab: "It disappears
+  from your dashboard and cannot be brought back. **Archiving keeps it.**" —
+  offered as an alternative to somebody standing in the archive, where it is not
+  an alternative at all.
+
+  The sentence now follows the ROW rather than the wording, and the state that
+  decides it is the one the seller would have to act on: whether `archived` is
+  still a move this listing has. An archived row (and a taken-down one) has spent
+  it and gets `listings.mine.delete_confirm_body.final` — the same warning
+  without the promise; a draft, a paused or an expired listing still has it and
+  still hears it. That is the row's own `available_transitions` and not a table
+  about its status: `<MyListingsPane>`'s confirmation hook is now given the
+  card's field, as the row's own controls have been since 0.22.0, so "a sold
+  listing may be archived" and "this one may" stop being the same claim.
+
 ## 0.25.10
 
 ### Patch Changes

package/MODULE.md

@@ -133,6 +133,7 @@ own length refusal under. One routing table covers both.
 | 1 | An owner-scoped list | **stapel-listings 0.7.0** — `GET my/listings/`, the caller's own rows in every status, `?status=` for a set, the same `IDAnchorPagination` envelope. `defaultMyListingsSource` is what the dashboard runs on; `MyListingsSource` survives as a seam for a host that keeps its rows elsewhere, and the missing-source error is gone rather than kept as a comment about something that no longer happens. |
 | 3 | `_get_own` in front of `update` / `partial_update` | **stapel-listings 0.6.2.** This pair still writes through `save-draft` (one write path is enough), but the endpoints are no longer a hole anything else that speaks the contract can walk through. |
 | 4 | An owner check on `retrieve` | **stapel-listings 0.6.2** — `ListingQuerySet.visible_to(user)`: a stranger's draft now 404s from the same code path an absent id does. The pair's `publiclyVisible` report stays, addressed at the one reader who still reaches an unpublished listing there: its owner. |
+| 7 | A counter for the takedowns | **stapel-listings 0.22.4** — `MyCountersResponse.blocked`, required beside the other three. D407's fourth tab was counted from its own unpaged `?status=blocked` page, which is right up to a page and blind past one; the badge is the server's now and the page is only the tab's rows. A deployment older than the field degrades to the page's length — never to a `0`, which is the defect wearing the new field. |
 
 ## 4. The three seams, and why none of them is an import
 
@@ -285,7 +286,8 @@ make it pass by copying the other package's keys in.
 the weight:
 
 - `status.test.ts` — the 9 × 4 table, the tab grouping (including BLOCKED,
-  which `my_counters` counts in no tab at all), and the transition mirror;
+  which the three paged tabs fold in nowhere and `my_counters` has counted
+  separately since 0.22.4), and the transition mirror;
 - `draft.test.ts` — the payload, in both directions: type tagging from the
   category schema, blanks omitted rather than nulled, the countable/stock
   cross-field rule, code-point length, the two kinds of publish 400;

package/README.md

@@ -111,6 +111,108 @@ nobody can read), and `signIn` is the door. `SignInCta` is core's, `{href}`
 **or** `{onSignIn}`, the same prop `@stapel/chat-react` and
 `@stapel/reviews-react` take. Omit it and the reason renders alone.
 
+The heart itself sits **on the photograph**, in its trailing top corner, on
+every card surface — the corner a thumb is already near, and the one corner of
+the strip that is free (the dots own the bottom centre, the "3 of 16" counter
+the bottom trailing). It is outside every anchor, because a link may not
+contain a control, and it stops a press from reaching the card behind it. Only
+the blocked visitor's REASON stayed in a row under the card, where there is a
+line for it to live on.
+
+## Save it, or send it to somebody
+
+The two verbs a reader has. Before 0.26 this pair had one of them, and the
+storefront had **no share control at all** — the only way to send somebody a
+listing was the address bar.
+
+```tsx
+<ListingDetailPane
+  id={id}
+  shareUrl={`/l/${id}`}                      // the canonical route, not location.href
+  onShared={(channel) => track("share", { channel })}
+  actionsPlacement="header"                  // default; "gallery" pins them over the photos
+/>
+```
+
+`<ListingActions>` is the cluster: the heart and `<ShareAction>` side by side,
+icon-only, each with a 44px hit target, at the trailing edge of the title row
+(or pinned over the gallery with `actionsPlacement="gallery"`). A card's heart
+uses the smaller 36px tier with a cursor and the same 44px with a thumb — both
+stated once, as a class contract, in `actionRow.ts`.
+
+**Sharing has two arms and the device picks.** Where `navigator.share` exists —
+every phone, almost no desktop — a press opens the PLATFORM sheet with
+`{title, text, url}`: the person's own apps, in their own order. Where it does
+not, it opens a menu: copy the link, Telegram, WhatsApp, VK. Every outbound
+link is `target="_blank"` with `rel="noopener noreferrer"`, and every field is
+`encodeURIComponent`-encoded, because a seller's title contains `&` and `#` in
+the wild and a raw one truncates the link the recipient receives.
+
+**The URL is yours.** `shareUrl` is used verbatim (a path is resolved against
+the document base); `window.location.href` is consulted only when a host
+supplies nothing, because the address a visitor is standing on carries the SERP
+query they arrived from and whatever tracking parameters came with them.
+
+**The same cluster can be in two places, and is one thing.** A phone reads the
+listing page over four screens, so past the first one a classified draws a
+condensed bar: back, the title, the two verbs. `actionsPlacement` takes a LIST
+for that, and `renderActionsBar` is handed the cluster's MOUNT POINT — not a
+copy of the cluster:
+
+```tsx
+const [inFold, setInFold] = useState(true);
+
+<ListingDetailPane
+  id={id}
+  actionsPlacement={["header", "bar"]}   // home, plus the place it may travel to
+  onTitleVisible={setInFold}             // an IntersectionObserver on the pane's own <h1>
+  renderActionsBar={(cluster) =>
+    inFold ? null : <div className="topbar">{back}{title}{cluster}</div>
+  }
+/>
+```
+
+`<ListingActions>` is rendered ONCE, through a portal, and the portal's
+container is moved between the two mount points as a DOM node. So the cluster
+mounts once, holds one `useFavoriteToggle`, and is literally the same element
+in both placements — a favourite in flight survives the move, and a probe
+counting `listings-detail-reader-actions` still finds exactly one. Return
+`null` from `renderActionsBar` and the cluster goes home; ask for `"bar"`
+without the render prop and nothing changes at all. `onTitleVisible` fires on
+each crossing and never on a scroll frame, and is not called at all in an
+environment with no `IntersectionObserver` — "this page cannot tell" is an
+answer and `true` would not be.
+
+**The photographs take the shape the host names.** `galleryLayout="grid"`
+(default) is the element-width grid this pane has always drawn;
+`galleryLayout="strip"` is a snap-scrolling horizontal strip, one photograph
+visible with the next peeking. On a 390px phone the grid resolves to one
+column, and a listing with three pictures pushes its own title and price nearly
+three screens down. The host names it, like `layout` and for the same reason —
+the side that knows the viewport it granted decides. And the pane no longer
+writes `display` inline: it is on `LISTINGS_GALLERY_CLASS` with a
+`data-gallery-layout` attribute (`detailGalleryCss()` is exported), so a host
+that wants a third shape at its own breakpoints writes a selector rather than
+an `!important` over a pair's geometry.
+
+**Confirmations are said twice.** "Link copied" stands inside the open menu AND
+goes out as a two-second toast; the heart's fill is the state and
+"Added to favourites" is the acknowledgement. The toast seam is antd's own —
+`App.useApp().message` where the host mounted `<App>`, antd's static `message`
+otherwise — so there is no new dependency and no host wiring.
+
+**A host switches either action off**, and the old node slot is untouched:
+
+```tsx
+<ListingDetailPane id={id} actions={{ share: false }} />          {/* no share button */}
+<ListingDetailPane id={id} actions={<ReportButton id={id} />} />  {/* extra chrome, as before */}
+```
+
+Headless hosts get the same answers without antd: `useShare({ url, title, text })`
+returns the resolved absolute url, whether the platform sheet exists, the three
+encoded hrefs, and the clipboard write with its `copied`/`copyFailed` states —
+plus `shareLinks()` as a pure function of `{url, title}`.
+
 ## Submitting a listing
 
 Four contracts meet on the composer, and three of them arrive as seams rather
@@ -268,15 +370,26 @@ own config. Nothing about the contract is required for a card to draw.
 0.7.0) is the owner-scoped read `GET /listings/` cannot be: `list` answers
 `published()` and takes no owner parameter, so before 0.7.0 a seller's own
 drafts were unreachable by any call the contract offered and this pane named
-the absence instead of drawing an empty grid. Three tabs, each narrowed with
-`?status=` to the SERVER's own groupings, so a tab's rows and its
-`my/counters` badge always describe the same set. `MyListingsSource` is still
-a seam for a deployment that keeps its rows elsewhere.
-
-**The takedown is not in a tab.** `blocked` is counted by `my/counters` in no
-tab at all, so folding it into one would make a badge and its rows disagree,
-and leaving it out would hide the one listing whose owner most needs to know.
-It is fetched beside the tabs and rendered above them.
+the absence instead of drawing an empty grid. Three counted tabs, each
+narrowed with `?status=` to the SERVER's own groupings, so a tab's rows and
+its `my/counters` badge always describe the same set. `MyListingsSource` is
+still a seam for a deployment that keeps its rows elsewhere, and it is typed
+for those three.
+
+**The takedown gets a fourth tab, and a count (D407).** `blocked` is counted
+by `my/counters` in no tab at all, so a cabinet holding a listing a moderator
+had pulled read "Active 0 · Drafts 0 · Archived 0" over it — the row was on
+the page, in no tab, in no number. It is now the `removed` tab: fetched off
+the same route (`?status=blocked`, unpaged, whichever tab is open) and counted
+by `MyCountersResponse.blocked`, the fourth integer stapel-listings 0.22.4
+added beside the other three. The rows were the count until that release and
+are still the count for a deployment whose server predates it — never a `0`,
+which is the one answer that would put the defect back. The
+tab is drawn only where there is something in it or `?tab=removed` asks for
+it, and a one-line warning above the tab strip says how many there are without
+waiting for a click. Not folded into `archived`: that tab reads the server's
+`archived` number, which does not include takedowns, so the count would go on
+being wrong for everyone not looking at it.
 
 **A draft renders off its twin.** `title` / `price` / `images` are the
 PUBLISHED fields and are empty until a publish promotes them, so the owner

package/dist/api/generated/schema.d.ts

@@ -436,15 +436,18 @@ export interface paths {
             cookie?: never;
         };
         /**
-         * @description Listings CRUD plus owner lifecycle actions and favorites.
+         * @description One integer per cabinet tab, over the caller's own listings.
          *
-         *     Read and write live in one class, so the guest wall
-         *     (:func:`anonymous_write_refusal`, the ``ALLOW_ANONYMOUS_WRITES`` switch)
-         *     is applied per ACTION and never as a class permission: an anonymous
-         *     session must keep browsing and keep its favorites, and only the
-         *     authorship actions — ``create``, ``update``/``partial_update``,
-         *     ``save-draft``, ``publish`` — are the ones that turn a caller into a
-         *     seller.
+         *     The tab groupings are the SERVER's — ``my/listings?status=`` takes
+         *     the same sets — so a cabinet never has to re-derive which statuses
+         *     make up "active". Every lifecycle status is in exactly one group:
+         *     ``blocked`` (a moderation takedown) is its own count rather than
+         *     being folded into ``archived``, because the two tell the seller
+         *     different things and only one of them is theirs to undo.
+         *
+         *     Owner-scoped at the queryset via ``owned_by``, soft-deleted rows
+         *     excluded by the default manager — the same scope as
+         *     ``my/listings``, so a tab's rows and its count always agree.
          *
          *     **Permissions:** `IsAuthenticated`
          */
@@ -497,7 +500,7 @@ export interface paths {
          * @description The caller's OWN listings, in every status.
          *
          *     The counterpart of ``my/counters``: the same owner scope and the same
-         *     status grouping, but the rows behind the three numbers. ``list`` is
+         *     status grouping, but the rows behind the four numbers. ``list`` is
          *     the shop window (``published()``, narrowable to nobody), so this is
          *     the only route by which a person can be shown their own drafts.
          *
@@ -1053,6 +1056,7 @@ export interface components {
             lat_draft?: string | null;
             /** Format: decimal */
             lon_draft?: string | null;
+            /** @description The WRITE shape of features_draft: an object keyed by feature slug, each value a FeatureDto — e.g. {"mileage":{"type":"int","value":42000}}. A listing READ hands back features as a *list* of decorated DAOs instead (`features` / `features_title` / `features_badges` — `{slug, name, label, presentation, …}`); posting that same list back here is also accepted, e.g. [{"slug":"mileage","type":"int","value":42000}] — only `slug`, `type` and `value` are read back out, every other (decoration) key is ignored. A malformed payload of either shape gets a features_draft_shape / features_draft_value_shape / features_draft_unknown_slug 400 naming the shape that would have worked. */
             features_draft?: {
                 [key: string]: components["schemas"]["FeatureDto"];
             } | null;
@@ -1125,11 +1129,18 @@ export interface components {
          * @enum {string}
          */
         ModerationStatusEnum: "not_submitted" | "pending" | "approved" | "rejected" | "needs_review";
-        /** @description Listing counts by tab for the current user. */
+        /**
+         * @description Listing counts by tab for the current user.
+         *
+         *     One integer per cabinet tab, and every lifecycle status belongs to
+         *     exactly one of them — ``blocked`` included, so a listing a moderator
+         *     took down is counted somewhere instead of vanishing from the totals.
+         */
         MyCountersResponse: {
             active: number;
             archived: number;
             drafts: number;
+            blocked: number;
         };
         /**
          * @description The owner's own card — the public card plus what only an owner sees.
@@ -1283,6 +1294,7 @@ export interface components {
             lat_draft?: string | null;
             /** Format: decimal */
             lon_draft?: string | null;
+            /** @description The WRITE shape of features_draft: an object keyed by feature slug, each value a FeatureDto — e.g. {"mileage":{"type":"int","value":42000}}. A listing READ hands back features as a *list* of decorated DAOs instead (`features` / `features_title` / `features_badges` — `{slug, name, label, presentation, …}`); posting that same list back here is also accepted, e.g. [{"slug":"mileage","type":"int","value":42000}] — only `slug`, `type` and `value` are read back out, every other (decoration) key is ignored. A malformed payload of either shape gets a features_draft_shape / features_draft_value_shape / features_draft_unknown_slug 400 naming the shape that would have worked. */
             features_draft?: {
                 [key: string]: components["schemas"]["FeatureDto"];
             } | null;
@@ -1354,8 +1366,6 @@ export interface components {
             labels?: string[];
             vocabulary?: string | null;
             level?: string | null;
-            prefix?: string | null;
-            postfix?: string | null;
         };
         /** @description Serializer for the ref_select feature DTO. */
         RefSelectDto: {