Tensor developer documentation, May 2026

Prepared for: Tensor Foundation, Developer Hub team Date of review: 2026-05-29 (V2 issuance; original review 2026-05-28) Documents reviewed: dev.tensor.trade documentation corpus mirrored 2026-05-27 — 93 files (~350 KB) covering /docs/, /reference/, /recipes/, /changelog/ Review type: Documentation quality, correctness, and developer-integration-readiness assessment

---

Executive summary

The Tensor REST API documentation set is structurally complete (90 of 92 enumerated URLs returned 200) and serves its primary purpose: documenting the published REST + WebSocket API surface alongside SDK references and integration recipes. The corpus carries 21 findings across the documentation quality dimensions reviewed.

Documentation is usable for integration but the issues catalogued below introduce avoidable friction for developers, with one finding (F-1) representing a category of issue that materially misleads integrators reading the affected pages.

Top-priority items requiring attention:

The CRITICAL item (F-1) is the most acute developer-experience issue: any developer reading the affected pages to integrate the documented endpoints will write code against the wrong shape, fail at integration, and need to find the correct counterpart endpoint pages through trial-and-error. Remediation is mechanical (replace 7 files with correct content or delete and redirect) and removes the largest source of integration friction in the corpus.

---

Methodology

The review was a systematic read-through of every file in the documentation mirror, applying a documentation-quality checklist tuned for vendor-published REST/WS API surfaces. The checklist covered:

• Content integrity (per-endpoint title ↔ tags ↔ path ↔ parameter set internal consistency)
• Response schema completeness
• Identifier and endpoint canonicity (base URLs, subdomains, auth header naming)
• WebSocket message shape consistency across reference and recipe surfaces
• Code sample correctness against current SDK versions (@solana/web3.js@^2.0.0)
• Deprecation and lifecycle hygiene (dates, deprecated programs, stale enum members)
• Cross-link and cross-reference integrity
• Security scheme metadata consistency
• Renderer portability (markdown vs. JSX-wrapped content)
• Capability claim vs. schema enum alignment (e.g., "any SPL currency" vs. Currency enum)
• Mirror coverage gaps (fetch-time 404s, undocumented adjacent surfaces)

Each finding was severity-graded against developer-impact criteria:

• Critical — Reader misled into writing wrong code; class-wide doc surface affected
• High — Material integration friction; non-obvious workaround required
• Medium — Friction reducible by reader effort; doc quality observable
• Low — Cosmetic inconsistency; affects polish, not function
• Informational — Advisory observation; no action strictly required

Findings IDs are opaque sequence numbers (F-1 through F-21) with no semantic content outside this report.

---

Findings

Critical

F-1 — Seven reference pages contain content from a different API

Unchanged Re-check of the published text, 11 October 2026.

Category. Documentation content integrity Affected files.

• dev.tensor.trade/reference/getbuy
• dev.tensor.trade/reference/getcancel
• dev.tensor.trade/reference/getedit
• dev.tensor.trade/reference/getlist
• dev.tensor.trade/reference/getlistings
• dev.tensor.trade/reference/getapproveseat
• dev.tensor.trade/reference/getinitializemarket

Observation. All seven pages are titled "SFT DEX API" (version 1.0.0), tagged ["SFTs"], marked [Devnet Only], and document parameters that describe Phoenix-style semi-fungible-token DEX operations rather than Tensor's NFT marketplace operations. Examples:

• getbuy documents parameters trader, market, amount (double), orderType (IOC/FOK) — these are SFT trading params, not NFT-buy params
• getlist documents payer, maker, market, priceInTicks, numBaseLots — SFT listing params
• getlistings documents a market public key parameter for retrieving a market's listings — SFT-market shape

The actual Tensor NFT marketplace counterparts exist at:

• reference/buytx-1.md (path /tx/buy, tagged Marketplace, with buyer/mint/owner/maxPrice/blockhash parameters)
• reference/cancelbidtx.md, reference/editbidtx-1.md / reference/editlistingtx-1.md, reference/listtx-1.md
• reference/getactivelistingsschema.md (the correct "Listings" reference)

Developer impact. A developer reading getbuy.md to integrate Tensor NFT buy will write code against parameters that don't exist on the actual /tx/buy endpoint. The pages don't carry any banner indicating they describe a different product; the URL slugs strongly suggest they ARE the Tensor NFT endpoints.

Recommendation. Replace each of the seven pages with the correct Tensor NFT marketplace content, OR delete the pages entirely and redirect the URLs to the canonical counterparts (buytx-1, cancelbidtx, editbidtx-1, editlistingtx-1, listtx-1, getactivelistingsschema). The recipes (recipes/buy-floor-nft.md and recipes/place-a-bid-within-5-of-floor-price.md) already use the correct /tx/* paths through the proper counterpart pages, so consumer code following recipes is not affected — only consumers reading the standalone reference pages.

---

High severity

F-2 — 25 query endpoints document no 200 response schema

Unchanged Re-check of the published text, 11 October 2026.

Category. API contract specification — response shape coverage Affected files. 25 reference pages including getcollectionbids, gettraitbids, getmintsbycollid, getactivelistingsschema, getactivity, getcollectiontxhistory, the entire getuser* group (8 pages), getnftbids, gettammorders, getammorders-1, getuserescrowaccounts, getuserportfoliocollections, gettraitbidattributes, getwhitelistinfo, depositwithdrawescrowntx-1 (200 response), and others.

Observation. Each affected OpenAPI specification declares the 200 response as { "schema": {} } — an empty object schema with no documented field types, no required-field list, no example payload. Integrators must reverse-engineer response shapes by inspecting live API call results.

Developer impact. Doubled integration time per affected endpoint: developers cannot generate typed clients from the OpenAPI spec, cannot validate response payloads at boundary, and cannot reason about nullable vs required fields ahead of integration. Most affected endpoints are query endpoints frequently consumed at high call volume.

Recommendation. Populate response schemas with at minimum: required-field list, field types, nullability flags. For complex responses (e.g., getcollectionbids, getactivity), include a sample payload as examples per OpenAPI spec — this is the lowest-effort path to disambiguating shape.

F-3 — Server URL inconsistency between OHLC reference and recipe code

Unchanged Re-check of the published text, 11 October 2026.

Category. Identifier and endpoint canonicity Affected files.

• reference/get-ohlc.md declares server https://api-tradingview.mainnet.tensordev.io (no /api/v1 path; no /tv/history in server URL)
• recipes/calculate-collection-moving-average.md line 49 uses https://api-tradingview.tensordev.io/tv/history — without the .mainnet subdomain infix

Observation. The two URL forms are mutually inconsistent. A developer cannot derive one from the other; both are presented as canonical in their respective contexts.

Developer impact. Recipe runs against one server URL; copy-paste-from-reference would target a different URL. Initial integration likely succeeds (whichever URL the developer happens to copy), but workflow tooling that generates a typed client from the OpenAPI spec then uses the recipe's URL pattern will silently misroute requests.

Recommendation. Reconcile to a single canonical URL across reference and recipe. Whichever form is selected, ensure the OpenAPI servers[].url value matches verbatim what working code samples actually use.

F-4 — WebSocket subscription payload key inconsistency

Unchanged Re-check of the published text, 11 October 2026.

Category. API contract specification — WebSocket message shape Affected files.

• recipes/websockets-stream-new-transactions-for-a-collection.md line 24: payload field "slug": COLLECTION_SLUG
• reference/newtransaction.md line 14: payload field collId: "Collection ID"
• reference/subscription-api-endpoints.md table: argument documented as collId: string

Observation. Three documents disagree on the payload field name for the newTransaction event subscription. The recipe uses slug; the reference and the subscription overview use collId.

Developer impact. Subscription messages constructed from the recipe will not match the server's expected field name (or vice versa); subscription silently fails or fails noisily depending on server-side strictness. Diagnosis requires reading server-side documentation outside the consumer's own code.

Recommendation. Standardize on collId (matches the subscription endpoint table, which appears authoritative). Update the recipe accordingly.

F-5 — Propagated code-sample bugs across recipes

Unchanged Re-check of the published text, 11 October 2026.

Category. Code sample correctness Affected files.

• recipes/buy-floor-nft.md
• recipes/place-a-bid-within-5-of-floor-price.md
• reference/tensor-transactions.md
• recipes/bid-wall-discovery.md

Observation. Three distinct bugs appear across the recipe code samples:

(a) Iteration index error. In buy-floor-nft.md line 61 and place-a-bid-within-5-of-floor-price.md line 59, the deserialization loop reads:

const txsToSign = response.txs.map((tx) =>
    tx.txV0
      ? VersionedTransaction.deserialize(response.txs[0].txV0.data)
      : Transaction.from(tx.tx.data)
);

The deserialization should reference the iteration variable tx.txV0.data, not the indexed response.txs[0].txV0.data. If the API returns more than one transaction, the recipe processes only the first one repeatedly. The same bug appears in reference/tensor-transactions.md line 95.

(b) **Wrong confirmTransaction argument shape.** buy-floor-nft.md line 68 and place-a-bid-within-5-of-floor-price.md line 67 use:

await connection.confirmTransaction(sig, { blockhash: "confirmed" })

The @solana/web3.js confirmTransaction API takes either a Commitment string ("confirmed"/"finalized"/etc.) or a TransactionConfirmationStrategy object containing signature/blockhash/lastValidBlockHeight. The current usage passes a malformed { blockhash: "confirmed" } object. The same reference/tensor-transactions.md line 109 uses the correct confirmTransaction(sig, "confirmed") — internal inconsistency between the official quickstart and the recipes.

(c) Environment variable name mismatch. recipes/bid-wall-discovery.md line 4 reads process.env.COLLECTION_ID, but the shell run-instructions at line 193 set COLLECTION_SLUG=.... The recipe will not run without the integrator renaming one or the other.

Developer impact. Each bug requires a debugging cycle to identify (none surfaces with a clear error message). Compounded impact: developers copying patterns across multiple recipes propagate the same bugs into their own codebases.

Recommendation. Patch each recipe's code block; align tensor-transactions.md example with the recipe pattern (and prefer the correct form). Consider adding a continuous-integration check that runs recipe code blocks against a known testnet to catch this category of bug.

F-6 — Legacy TSwap pool-operation endpoints not marked deprecated

Unchanged Re-check of the published text, 11 October 2026.

Category. Versioning & deprecation Affected files.

• reference/tswapeditpooltx-1.md
• reference/tswapclosepooltx-1.md
• reference/tswapdepositwithdrawsoltx-1.md
• reference/createtswapdepositwithdrawtx-1.md

Observation. Per docs/program-changes.md, the TSwap program has been narrowed to shared-escrow-only — pool operations migrated to the AMM program. The four affected pages document TSwap pool operations as if they were live, with no banner, deprecation notice, or pointer to the replacement endpoints (tammeditpooltx.md, tammclosepooltx.md, tammdepositwithdrawsoltx.md, tammcreateordertx.md).

Developer impact. Developers searching for "Tensor pool edit transaction" land on tswapeditpooltx-1 first (lexicographic ordering puts T before T... — but they're both T-prefixed; reference page lookup is by slug, and the legacy endpoint slug doesn't signal deprecation). Integration against deprecated endpoints proceeds without warning.

Recommendation. Add a banner block at top of each of the four files: "This endpoint is deprecated. Pool operations have moved to the AMM program — see /reference/tammeditpooltx (etc.)". Optionally redirect the legacy URLs.

F-7 — Unsubscribe documentation does not document subscriptionId derivation

Unchanged Re-check of the published text, 11 October 2026.

Category. Cross-reference integrity Affected files. reference/unsubscribe.md — and absence of subscriptionId field documentation in subscribe-event response pages (newtransaction.md, tcompbidupdate.md, tcompbidupdateall.md, ammorderupdate.md, ammorderupdateall.md).

Observation. The unsubscribe message documents an argument subscriptionId: string, but none of the subscribe-event response documentation includes subscriptionId in the response shape. The integrator cannot determine where to obtain the value to pass.

Developer impact. Unsubscribe path is undiscoverable from documentation alone; requires live-call inspection of subscribe response to find the field.

Recommendation. Document the subscriptionId field in each subscribe-event response, OR add a paragraph to reference/unsubscribe.md explaining where the value comes from in the subscribe acknowledgement.

---

Medium severity

F-8 — Six distinct OpenAPI document titles within one API documentation set

Unchanged Re-check of the published text, 11 October 2026.

Category. Documentation taxonomy Observation. Reference pages declare six different info.title values: "Trading API", "Data API", "SDK API", "Refresh API", "SFT DEX API" (the seven incorrect pages from F-1), and "tv-api". No overview document explains which surfaces belong to which "API". Consumers using OpenAPI-driven client generators will produce six distinct typed-client namespaces with no documented relationship.

Recommendation. Consolidate titles to a single value (e.g., "Tensor REST API") or document the surface taxonomy explicitly in docs/overview.md.

F-9 — Past timeline events framed as upcoming

Unchanged Re-check of the published text, 11 October 2026.

Category. Versioning & deprecation Affected files.

• changelog/sunsetting-price-lock.md references October 9 2024 / November 2 2024 deadlines as if forthcoming
• changelog/migration-delay.md references October 9th as a pending date
• changelog/migration-delay-20.md describes a deferred deployment without a resolution marker

Observation. Current date is 19 months past the cited deadlines. No "resolved" or "this happened" markers added.

Recommendation. Add resolution timestamps to historical changelog entries; consider archiving entries older than 12 months to a separate "Historical announcements" section.

F-10 — Stale data-source and transaction-type enum members

Unchanged Re-check of the published text, 11 October 2026.

Category. API contract specification — enum currency Affected files.

• reference/getactivelistingsschema.md and reference/getmintsbycollid.md: DataSource enum (31 values) includes long-defunct or merged sources: HYPERSPACE (shut down 2023), SOLANART, SOLSEA, YAWWW, ELIXIR, ELIXIR_COMPOSED, DIGITALEYEZ, DIGITALEYEZ_V2, SMB_V2, MAGICEDEN_AUCTION, SWAPSORIAN, TROLL, plus TENSORSWAP + TENSORBID (documented as deprecated/migrated in docs/program-changes.md).
• reference/getactivity.md: TransactionType enum (60+ values) includes deprecated SWAP_* operations (moved to Marketplace), ELIXIR_* (8 values), MARGIN_* (6 values), AUCTION_* (4 values) — many representing programs no longer active or accessible.

Observation. Enums include values consumers can no longer plausibly observe in current production responses.

Recommendation. Mark legacy enum values with a comment or move to a separate "deprecated values" subsection. At minimum, document which enum members correspond to live data flows vs historical data.

F-11 — Currency enum coverage gap vs documented capability

Unchanged Re-check of the published text, 11 October 2026.

Category. Capability claim vs schema alignment Affected files. reference/refreshmetadata-1.md (Currency enum at lines 53-58); docs/program-changes.md (lines 27-28).

Observation. program-changes.md states: "Listings can specify any SPL as currency. Non-SOL orders won't show up on the Tensor.Trade frontend, but can easily be integrated in any custom frontend." This implies arbitrary SPL token mint addresses as currency. But refreshmetadata-1.md's Currency enum constrains to two values only: SOL_LAMPORT and ETH_WEI.

The transaction endpoints (listtx-1, buytx-1, selltx-1, etc.) accept an arbitrary currency mint-address string parameter, consistent with the capability claim. So the inconsistency is between display-side enum (closed) and transaction-side parameter (open).

Recommendation. Either expand the Currency enum to include real-world SPL currencies Tensor displays prices in, OR document explicitly that the display-side enum is the subset of currencies Tensor.Trade renders price for (and arbitrary SPL is supported at submission but rendered as raw lamports in the public UI).

F-12 — TB1D deprecation lacks migration breadcrumb

Unchanged Re-check of the published text, 11 October 2026.

Category. Cross-reference integrity Affected files. docs/program-changes.md (line 16); absence of cross-reference in single-NFT-bid reference pages.

Observation. Per program-changes.md, "TB1D is deprecated and all of its functionality got moved to Marketplace." There is no tb1d* documentation file in the corpus (correct — the program is deprecated). However, integrators searching the documentation for "TB1D" (which they may know from older Tensor documentation, blog posts, or third-party tutorials) find nothing. The single-NFT bid replacement (singlebidtx-1.md) does not carry a "Previously TB1D" cross-reference.

Recommendation. Add a sentence to docs/program-changes.md like "For single-NFT bid construction, use the Marketplace program — see /reference/singlebidtx-1". Optionally add the same cross-reference inline at singlebidtx-1.md.

F-13 — Broken internal links and 404 in API-key application path

Unchanged Re-check of the published text, 11 October 2026.

Category. Cross-reference integrity Affected files.

• reference/websockets.md line 66: link to /recipes/websockets-stream-new-transactios-for-a-collection — typo in slug (transactios missing 'n'); link 404s.
• docs/getting-started-1.md line 31: "Apply for an API key here". The path /page/tensor-api-form does not resolve. Attempting to fetch the documented form page returns 404.

Observation. Two distinct broken-link issues: one typo, one missing destination page. The API-key application path is the more impactful — it gates developer access entirely.

Recommendation. Fix the typo. Audit the API-key application page (does it exist? at a different path?). Either restore the path or update the link target.

F-14 — selltx parameter description copy-paste error

Unchanged Re-check of the published text, 11 October 2026.

Category. API contract specification Affected file. reference/selltx-1.md line 159.

Observation. Parameter minPrice carries the description "The maximum price that would be paid for the NFT" — this is the description for maxPrice in buytx-1.md. For a sell transaction, minPrice is the minimum acceptable bid the seller will accept.

Recommendation. Correct the description string to reflect the semantics of minPrice for a sell transaction (e.g., "The minimum price the seller will accept for the NFT").

F-15 — REST API Quickstart is 12 lines and omits all integration prerequisites

Unchanged Re-check of the published text, 11 October 2026.

Category. Developer experience — onboarding Affected file. reference/quickstart.md.

Observation. The "REST API Quickstart Guide" documents only the API-key application path and the "Try-it-on-Developer-Hub-UI" feature. It does not include: base URL, authentication header format, a minimum-viable request example, a sample curl invocation, or pointers to the recipes section. A developer arriving at the Quickstart page does not leave it with enough to make a first request.

Recommendation. Expand to include: base URL, auth header (x-tensor-api-key: <key>), a minimum-viable curl/JS example, and explicit links to the Recipes for end-to-end patterns.

F-16 — Auth-exempt endpoint not surfaced in overview documentation

Unchanged Re-check of the published text, 11 October 2026.

Category. Developer experience — surface Affected files. reference/getmintproof-1.md (line 5 explicitly states "This endpoint does not require an API key"); not surfaced in docs/getting-started-1.md, docs/overview.md, or reference/quickstart.md.

Observation. The getmintproof endpoint is auth-exempt, which is a meaningful integration detail (saves API-key rate-limit budget on a frequently-used proof endpoint). It is documented only on its own page, not in the overview docs where consumers planning rate-limit strategies would look.

Recommendation. Add a "Public (no auth) endpoints" subsection to either getting-started-1.md or quickstart.md enumerating which endpoints are auth-exempt.

F-17 — Mirror coverage gap: convenience-surface endpoints not in main documentation hub

Could not check Re-check of the published text, 11 October 2026.

Category. API surface coverage Observation. Tensor publishes a parallel API surface at tensor.dial.to/* (Solana Action / Blink primitives, e.g., tensor.dial.to/buy-floor/<collMint>?filters=<base64>). Tensor's own blog (blog.tensor.trade, e.g., "Don't Blink: Solana Actions Take Over X") positions these as social-embed primitives. Some developers and aggregator integrations consume these endpoints from backend code, treating them as a no-auth alternative to the REST API.

The dev.tensor.trade documentation set does not document the tensor.dial.to surface at all. Developers consuming Blink endpoints from backends have no documented contract to verify against; their usage drifts into the "use until throttled" pattern.

Developer impact. Backend consumption of convenience-surface endpoints intended for one-click social embeds tends to incur silent rate-limit / IP-reputation throttling that the consumer cannot predict from documentation alone. Production-tier integration via the REST API is the documented path but the boundary between the two surfaces is not communicated.

Recommendation. Either (a) add a "Surface guide" page to docs/ explicitly delineating Blink/Action endpoints (intended for one-click consumer flows) vs REST API endpoints (intended for backend / aggregator consumption), with guidance on when to use each; or (b) explicitly state that tensor.dial.to endpoints are not for sustained backend consumption and the REST API is the documented alternative.

F-18 — Production-readiness disclaimer on REST API

Unchanged Re-check of the published text, 11 October 2026.

Category. Lifecycle communication Affected file. reference/quickstart.md line 3.

Observation. Quickstart includes "This API is in Alpha! Breaking changes may occur without warning!" — a meaningful caveat that affects consumer-side planning (e.g., schema-drift monitoring, version-pinning strategy).

Recommendation. Either graduate the REST API out of Alpha (with stability commitment to a versioned shape), or document the breaking-change announcement channel (the changelog/ section? a Discord channel?). Currently the disclaimer reads as a global "use at your own risk" without remediation guidance.

---

Low severity

F-19 — securityScheme name inconsistency

Unchanged Re-check of the published text, 11 October 2026.

Category. OpenAPI metadata consistency Affected file. reference/get-ohlc.md names the security scheme sec0; the remaining 51 reference pages name it api_key. Both reference the same x-tensor-api-key header.

Recommendation. Rename sec0 to api_key for consistency. Tooling that generates typed clients from the OpenAPI spec will otherwise produce two distinct security-scheme types.

F-20 — Renderer-specific JSX wrappers in markdown content

Unchanged Re-check of the published text, 11 October 2026.

Category. Renderer portability Affected files.

• docs/new-fee-structure.md (uses <HTMLBlock> + inline <table> with inline CSS)
• docs/oss-repository-structure.md (100+ lines of <HTMLBlock> + <details> tree)
• docs/max-proof-length-for-tensor-cnfts.md (uses <Table align=...>)
• reference/tensor-transactions.md (uses <block:tutorial-tile>)

Observation. These markdown documents include JSX wrappers that render only on the readme.io-hosted vendor site. Any developer reading the documentation through a plain markdown viewer (offline mirror, API-based documentation aggregator, IDE markdown preview, AI-assistant context window) sees raw JSX as content.

Recommendation. Where structural content can be expressed in standard markdown (tables, lists, code blocks), prefer markdown. Reserve JSX wrappers for content that genuinely requires renderer features.

F-21 — WebSocket ping message shape inconsistency

Unchanged Re-check of the published text, 11 October 2026.

Category. API contract specification — WebSocket Affected files.

• reference/ping.md line 10: socket.send(JSON.stringify({ "event": "ping" })) — no payload field
• reference/websockets.md line 31-34: { "event": "ping", "payload": {} } — explicit empty payload

Observation. Two shapes documented for the same ping operation.

Recommendation. Standardize on the empty-payload form ({ "event": "ping", "payload": {} }) — more permissive parsing on both sides, consistent with payload-bearing events.

---

Informational

(F-18 above also carries an informational dimension; restated here for completeness of the lifecycle disclaimer observation.)

---

Summary by category

Summary by severity

---

Positive observations

Outside the finding catalog, several aspects of the documentation set are above the typical vendor-API-documentation baseline:

• The five-program semantic split (docs/overview.md, docs/program-changes.md) is clearly motivated and well-articulated; the rationale for the post-migration architecture is one of the clearest "why" statements in published Solana program documentation.
• The new fee structure documentation (docs/new-fee-structure.md) explicitly describes the maker/taker broker split and explains the model — most vendors document only the rates, not the model.
• The max-proof-length-for-tensor-cnfts.md document is a genuinely useful integration-prerequisite reference for cNFT integrators and the kind of operational guidance most vendors omit.
• The SDK-vs-REST distinction in docs/getting-started-1.md (lines 35-43) honestly communicates the tradeoffs ("SDK has no rate limiting, no API key, lower latency"); transparency on this kind of internal-tier distinction is uncommon in vendor docs and benefits sophisticated integrators.
• The WebSocket subscription model is conceptually clean, with a manageable event surface (per reference/subscription-api-endpoints.md).
• The OpenAPI specifications, where complete, follow standard conventions and produce usable typed clients for endpoints not affected by F-1 / F-2.

---

Closing

This documentation set is fundamentally serviceable. The findings catalogued above are documentation-quality issues, not protocol-level concerns. With focused remediation effort estimated at 4-8 weeks of documentation-team time, the corpus would move from "PASS WITH NOTES" to "PASS" with no caveats.

The single highest-leverage remediation is F-1 — replacing or removing the seven incorrect reference pages. Resolution of F-1 alone eliminates the only finding that materially misleads integrators about endpoint semantics; the remaining findings are reducible through reader effort but represent avoidable friction.

The reviewer is available for clarification on any finding, suggested remediation language, or follow-up review after remediation passes.

---

Prepared by: Ondřej Dvořák (Pukapasoft) Contact: [email available on request] Source of record: Documentation mirror dated 2026-05-27, fetched via published URL list of 92 entries plus referenced auxiliary surfaces. Version note: This is the V2 issuance (2026-05-29). Findings F-1 through F-21 are unchanged from the original 2026-05-28 review; the V2 marker reflects an internal reissuance cycle and does not signal new evidence or revised vendor-facing observations.