@petercjl/taobao-ai-ops 0.1.0 → 0.1.1

package/skills/taobao-search-product-form/references/report-output.md

@@ -1,23 +0,0 @@
-# Comprehensive report output contract
-
-Load this page at the `report` node. Its input is the run ledger and the completed modules' interpretation plus evidence artifacts, including any available cross-module evidence and opportunity cards. The report answers what product-side propositions merit further white-label research, why, and what evidence would change that assessment. It is a research report, not a binary entry authorization.
-
-## Assembly main line
-
-1. Resolve one coherent source run. Check source workbook identity, approved/verified module versions, natural-product population and advertising-row grain. The current visual prototype labels, prototype summary, comparison evidence, schema-2 opportunity cards and their source hashes form one linked version. Inspect the actual interpretation and evidence files. A changed visual classification requires new cross-module evidence, opportunity cards, visual interpretation and final report; unaffected modules from the same cleaned workbook may be reused after reconciliation. If a required module or source binding is absent, stop and reconcile before publishing.
-2. Build the report data manifest from the current run's artifact paths. The `visual` module includes `summary`, `labels` (`product_style_labels.json`) and `prototypes` (`style_prototype_summary.json`); the `decision` module includes `evidence` and `cards`. Each opportunity-card document stores the comparison file's SHA-256 in `source_evidence_sha256`. A supplied visual interpretation Markdown starts with `<!-- source_prototype_summary_sha256: <64-character SHA-256> -->`; a supplied decision interpretation starts with `<!-- source_evidence_sha256: <64-character SHA-256> -->`. These binding comments are file metadata and are removed from rendered prose. When no visual interpretation has been written for the current prototypes, omit that role and label the report's data-derived explanation accordingly. The bundled `scripts/build_report_viewmodel.py --manifest MANIFEST --output NEW_VIEWMODEL.json` is the deterministic adapter for the current JSON/Markdown artifact family. The manifest uses semantic module keys, relative paths resolved from the manifest directory, a title, subject, and source identity; it is run data, never bundled private content.
-3. Present a short executive reading path, then substantive independent chapters for input/cleaning, advertising, title roots, listing geography, price bands, visual form/style/task, candidate comparison, and opportunity judgment. Each completed analytical chapter contains its current-run written interpretation and evidence tables with explicit metric definitions and drill-down IDs. Use the source's numbered conclusions, bold leads, and labeled paragraphs as the semantic boundaries of numbered points. Each point states one complete judgment with its supporting figures, explanation, implication and relevant caveat together; its lead phrase is bold and its badge uses semantic color. Preserve every material finding, counterexample and limitation from the current interpretation; restructure headings and prose for reading without reducing the interpretation to a teaser. The visual chapter may synthesize its full-run label summary when no separately reviewed prose exists and must state that provenance. It includes structural-form and variant/configuration evidence tables plus a complete product-image gallery: one child menu per observed **whole-product style prototype**, with boundary and `未识图` menus when needed. Every natural product ID is covered; a listing may appear in several prototype menus when its image shows multiple actual styles, so menu counts cannot be added as unique products. Each card shows an HTTPS image, title, ID, shop, current price, displayed payment people, main form, variant/configuration, separate style, image-supported task, visual status and direct visible evidence. An original over 10 MB remains in the gallery and full numeric evidence with `未识图（图片不可用）` status and `too_large` reason; it has no inferred visual labels and does not enter visual candidate groups. Within each prototype show 50 items per page; sort the full prototype group before pagination by price, displayed payment, or the auditable research-priority score. Preserve the image-bound observations, prototype definitions, grouping reasons and uncertain cases in the run's audit; do not turn isolated visual features into report menus. Join the cleaned natural-position sheet's original `商品链接` to the gallery by product ID; verify URL scheme, marketplace host, embedded ID, source workbook hash and complete coverage. Each card has exactly two copy controls—ID and original link—and opening the image or title navigates to that link in a new tab. If links are unavailable or invalid in another input, expose the data gap instead of constructing a guessed product address.
-4. The opportunity section is the synthesis, with one child menu per selected card. A card identifies the physical merchandise proposition, observations, supporting and adverse evidence, parent/comparable context, representative product and shop IDs, unknowns, and the next discriminating checks. Research order is explained; it is not an opaque total score or a go/no-go decision.
-5. Provide a searchable evidence area including all natural products and candidate groups. Keep source text, IDs, titles, labels, price, displayed payment, shop, address and advertising linkage at their correct grains. The separate JSON artifacts remain the full machine-readable evidence. Before marking a report complete, verify the bundled template's requested column filtering and sorting in the generated HTML; missing controls keep the report stage `awaiting_review` for template development.
-6. Run `scripts/validate_report_viewmodel.py --manifest MANIFEST --viewmodel VIEWMODEL` before rendering to verify prototype-label/source binding, card/evidence binding, current interpretation versions, candidate/product/card coverage, and exact gallery membership per prototype. Reconcile every ready image to an observation and every unobserved product to a `too_large` manifest record; a missing readable-image observation fails QA. Render with the package's `scripts/render_report.py` and its bundled renderer, validator and template. The report ViewModel is a separate artifact. Use the export's approved HTTPS links for the full gallery; selected representative thumbnails may remain embedded. Preserve the independent image-review contact sheet as an audit artifact.
-
-The builder and validator match `visual.labels` to the comparison artifact's recorded prototype-label SHA-256, match `visual.prototypes` to each product's memberships, and match schema-2 opportunity cards to the exact comparison file SHA-256. These prototype memberships drive the gallery and allow justified repeat appearances across menus. Keep the source summary and three-axis labels as secondary evidence. The manifest is a run artifact, not a bundled category list.
-
-## Evidence and presentation invariants
-
-- Distinguish observed data, interpretation, counterevidence, unknowns and next research. Link each quantitative claim to the relevant row/group and product or shop ID; verify numbers against JSON, not merely against a prose file.
-- Natural product ID is the product grain. Advertising occurrences, unique ad IDs and same-shop natural overlap are different measures. Title roots and visual candidate groups overlap and their totals are not additive. A blank use-task label does not establish absence of use demand.
-- The export's `付款人数` has no stated time window; do not call it sales units, GMV, conversion or growth. Search-page price is not verified SKU transaction price. Title roots are seller claims. Listing address is not factory location. Image-supported task labels are not verified buyer demographics. A search snapshot does not establish trend, market share, ad spend, profit or white-label entry viability.
-- The gallery's **research-priority score** is a transparent within-snapshot evidence-review order, never a predicted profit, white-label opportunity, conversion or entry score. Current default: `60 × min(1, ln(1+displayed payment people)/ln(1+payment P99)) + 25 × (product's price-band natural-product count / largest-band count) + 15 × (whole-product prototype assigned ? 1 : 0)`, rounded to one decimal. Derive P99 and band counts from the current unique natural-product sample, handle an all-zero payment sample safely, display those denominators and the formula, and keep the component assumptions visible. Higher price-band supply is evidence coverage, not proof of demand. Revisit the strategy with the user as product-level evidence improves; never silently treat the score as the research-card order.
-- Present conclusions as short, labeled structured items, then numbered explanation points and evidence. Use semantic color and weight for pivotal claims and cautions. Let numbered source items and labeled source paragraphs define the point boundaries. Place the supporting explanation in the same point, with sufficient line spacing and selective emphasis; do not derive point boundaries from a fixed character count or punctuation. If a source paragraph contains several genuinely separate judgments, reorganize it by meaning and verify that each still has its relevant evidence and caveat. Preserve the complete approved interpretation content in readable chapter sections, including tables and case studies. Use only charts that make a comparison clearer than its table.
-- Validate chapter and artifact coverage, source totals, card reference resolution, alignment between source judgments and numbered report points, UI navigation, evidence search/filter/sort as supported, image loading, desktop/mobile overflow and print readability. A generated file is `awaiting_review` until the user accepts it; a main run is not a clean-context regression.

package/skills/taobao-search-product-form/references/source-manifest.md

@@ -1,37 +0,0 @@
-# Source manifest
-
-Coverage: partial. This is a shareable, self-contained synthesis, not a runtime dependency on a private Wiki.
-
-Source classes: W / U / E / A mean contextual Wiki synthesis, user-confirmed requirement, observed evaluation evidence, and design assumption respectively.
-
-- `U`: user-confirmed product-image grouping, 2026-09-30: the selection unit is a recognizable complete product style, not an isolated body-outline or presentation feature. A varied sample establishes provisional prototypes; new images are constantly compared and may add a new prototype or belong to several actual product schemes visible in one listing.
-- `E`: a reviewed 100-image milkpot pilot showed 11 coherent candidate product-style groups with 3 boundary products. Its exact taxonomy and counts are evaluation examples, not a reusable class list or market-share estimate.
-- `A`: a run-specific registry with representative images, inclusion/boundary rules and image-hash-bound per-product membership decisions is a portable execution contract. It still requires semantic image QA; structural/style/task observations are secondary evidence rather than the final taxonomy.
-
-- `U`: user-confirmed opportunity-card contract, 2026-09-28: combine visual classification with displayed payment evidence, price bands, merchant product-line layout and prior modules; show the grounds and counterevidence so the user judges whether to deepen research or initiate profit/supplier checks. Review HTML is not the final presentation contract.
-- `W`: general product-development and cost-structure knowledge supports demand before product, real product difference, net profit rather than gross sales, supplier standards and small-batch testing. It supplies later verification questions, not a search-snapshot scoring formula or a claim that a particular candidate is profitable.
-- `A`: assemble a deterministic product-ID evidence table; compare parent forms with only well-supported style/task intersections, test leading-shop/product dependence, and issue structured cards without an opaque total score. This is the proposed reusable comparison method for user review on the current sample.
-
-- `U`: user-confirmed requirement, 2026-09-27: product form starts with image inspection; natural listings define the form-performance population; advertised listings have separate competitive value; platform category is not an exclusion rule; exclude visibly irrelevant products and accessories.
-- `U`: user-confirmed workflow design, 2026-09-27: keep the stable business flow separate from replaceable classification and decision strategies; support stepwise development and low-interaction end-to-end runs; record each stage's state and intermediate artifact paths in a per-run ledger.
-- `U`: user-confirmed clean-stage rule, 2026-09-27: split natural and advertising placements into two tables; natural rows retain the first source occurrence of each product ID and exclude later natural duplicates. Advertising rows remain a separate display-record population.
-- `U`: user-confirmed advertiser module, 2026-09-27: use separate appearance, unique-product and exact-shop populations; profile which shops and products occupy advertising positions, how repeated appearances differ from promoted assortment, and whether products or exact shop names also appear naturally. Deliver machine-readable details and a separate evidence-backed text conclusion for later HTML composition.
-- `U`: user-confirmed conclusion depth, 2026-09-27: name the shops with frequent advertising appearances and compare their advertised products, unadvertised natural products, natural-row `付款人数`, and observed product price bands. The business conclusion must interpret merchant and merchandise patterns rather than restate only aggregate counts.
-- `U`: user-confirmed representative-shop depth, 2026-09-27: explain typical shops' specific merchandise layouts, the advertising configuration they exhibit, and what those cases imply for white-label product research. Keep the conclusion substantive enough to stand without the JSON detail.
-- `A`: select contrasting cases from observed advertising presence, assortment, natural-position payment evidence and price positioning; separate observed configuration, inferred intent and actionable research implication. Treat this as an interpretive method subject to user review.
-- `A`: choose price-band boundaries per run from the source distribution and record them with the output; use the same boundaries for advertising and natural comparisons. This is a configurable analysis method, not a fixed price threshold or entry rule.
-- `U`: user-confirmed title-root module, 2026-09-27: use only natural-position products; split each title into roots traceable to product ID, title, image, source `付款人数`, price and shop; examine root coverage, price distribution and shop assortment for white-label product/market research.
-- `A`: use a versioned protected-phrase lexicon plus optional reviewed project additions, record an immutable snapshot per run, and review frequent unclassified `jieba` segments before promoting them. Title terms are seller language rather than direct buyer-query counts; image evidence decides actual form.
-- `U`: user-confirmed geographic research direction, 2026-09-27: use the search export's address field to examine where visible products and shops cluster, what product propositions appear there, how comparable price/payment evidence looks, and whether advertising is present; output a method and run it on the current sample.
-- `A`: preserve product, shop and shop–address grains; use root–region coverage and a descriptive location quotient, shop concentration, matched price cohorts, and separate advertising appearance/product counts. Treat the address as an unverified listing label and require supplier evidence before calling a region a production cluster.
-- `U`: user-confirmed price-band method, 2026-09-27: price boundaries must be generated from each input sample rather than fixed in the Skill; all cleaned natural-position products participate in this module; any product-eligibility decision belongs upstream in the clean stage; use Jenks natural breaks.
-- `E`: published Jenks natural-breaks documentation describes data-specific clusters and unequal class populations; the current flat-pan sample supplies evaluation evidence, not reusable numeric price boundaries.
-- `A`: fit Jenks on log current price, select band count by a declared marginal explained-variance penalty and minimum support, test sensitivity and bootstrap stability, and interpret natural-product/merchant/payment and separate advertising context. The complexity penalty is a revisable strategy parameter, not a platform rule or consumer-cognition threshold.
-- `W`: a general ecommerce positioning note supports narrowing to a winnable product/need segment, but supplies no method for visual classification or search-snapshot measurement. The note predates this Skill and is used only as broad context.
-- `E`: a representative Taobao search export has repeated product IDs and products appearing in both natural and advertising positions; its exact counts are evaluation data, not universal business rules.
-- `A`: image-grounded taxonomy, separation of observable traction and white-label feasibility, and report presentation are proposed method design. Validate with user-reviewed runs.
-- `U`: user-confirmed visual-stage direction, 2026-09-27: read each image once for all dimensions; use bounded concurrent groups when genuinely available; discover labels during viewing, then aggregate centrally to avoid nearly unique labels per product.
-- `U`: user-confirmed selection meaning, 2026-09-27: structural form, product style and target audience/use task are parallel selection paths; style- or audience-led physical product differentiation can be a new candidate merchandise form even when base structure is unchanged.
-- `A`: image fingerprints for batch scheduling, a versioned canonical/alias registry, one-record-per-product provenance checks, and explicit unresolved-label review are implementation choices for that direction, pending user review of the pilot.
-
-Critical gaps: no verified conversion or GMV period for displayed payment counts; no advertising cost/ROI; no reviews, supplier economics or time series in a single search export. The export's address field does not verify the warehouse or factory location. Opportunity cards can order research but cannot establish entry readiness or profit. Recompile this layer when the user approves a better product-form taxonomy, card method or validated decision criteria.

package/skills/taobao-search-product-form/references/title-lexicon.json

@@ -1,55 +0,0 @@
-{
-  "schema_version": "1.0",
-  "description": "General ecommerce cookware title phrases. These are seller-language labels, not verified product materials, forms, or buyer queries.",
-  "entries": [
-    {"canonical": "平底锅", "facet": "form_claim", "surfaces": ["平底锅"]},
-    {"canonical": "深煎锅", "facet": "form_claim", "surfaces": ["深煎锅", "加深煎锅"]},
-    {"canonical": "煎炒锅", "facet": "form_claim", "surfaces": ["煎炒锅"]},
-    {"canonical": "煎锅", "facet": "form_claim", "surfaces": ["煎锅"]},
-    {"canonical": "早餐锅", "facet": "form_claim", "surfaces": ["早餐锅", "三合一早餐锅"]},
-    {"canonical": "牛排锅", "facet": "form_claim", "surfaces": ["牛排锅"]},
-    {"canonical": "煎蛋锅", "facet": "form_claim", "surfaces": ["煎蛋锅"]},
-    {"canonical": "烙饼锅", "facet": "form_claim", "surfaces": ["烙饼锅"]},
-    {"canonical": "玉子烧锅", "facet": "form_claim", "surfaces": ["玉子烧锅", "玉子烧"]},
-    {"canonical": "蛋饺锅", "facet": "form_claim", "surfaces": ["蛋饺锅"]},
-    {"canonical": "炒锅", "facet": "form_claim", "surfaces": ["炒锅"]},
-    {"canonical": "泼油锅", "facet": "form_claim", "surfaces": ["泼油锅", "热油锅"]},
-    {"canonical": "纯钛", "facet": "material_claim", "surfaces": ["纯钛"]},
-    {"canonical": "钛陶瓷", "facet": "material_claim", "surfaces": ["钛陶瓷"]},
-    {"canonical": "钛合金", "facet": "material_claim", "surfaces": ["钛合金"]},
-    {"canonical": "有钛", "facet": "material_claim", "surfaces": ["有钛"]},
-    {"canonical": "真钛", "facet": "material_claim", "surfaces": ["真钛"]},
-    {"canonical": "钛", "facet": "material_claim", "surfaces": ["钛"]},
-    {"canonical": "铸铁", "facet": "material_claim", "surfaces": ["铸铁"]},
-    {"canonical": "精铁", "facet": "material_claim", "surfaces": ["精铁"]},
-    {"canonical": "熟铁", "facet": "material_claim", "surfaces": ["熟铁"]},
-    {"canonical": "不锈钢", "facet": "material_claim", "surfaces": ["不锈钢"]},
-    {"canonical": "304不锈钢", "facet": "material_claim", "surfaces": ["304不锈钢"]},
-    {"canonical": "316L不锈钢", "facet": "material_claim", "surfaces": ["316L不锈钢", "316l不锈钢"]},
-    {"canonical": "麦饭石", "facet": "material_claim", "surfaces": ["麦饭石"]},
-    {"canonical": "无涂层", "facet": "surface_claim", "surfaces": ["无涂层", "0涂层", "零涂层"]},
-    {"canonical": "不粘", "facet": "surface_claim", "surfaces": ["不粘", "不沾"]},
-    {"canonical": "无氟", "facet": "surface_claim", "surfaces": ["无氟"]},
-    {"canonical": "蜂窝", "facet": "surface_claim", "surfaces": ["蜂窝"]},
-    {"canonical": "聚油", "facet": "surface_claim", "surfaces": ["聚油"]},
-    {"canonical": "火红点", "facet": "surface_claim", "surfaces": ["火红点"]},
-    {"canonical": "煎蛋", "facet": "use_claim", "surfaces": ["煎蛋"]},
-    {"canonical": "煎饼", "facet": "use_claim", "surfaces": ["煎饼"]},
-    {"canonical": "牛排", "facet": "use_claim", "surfaces": ["牛排"]},
-    {"canonical": "烙饼", "facet": "use_claim", "surfaces": ["烙饼"]},
-    {"canonical": "早餐", "facet": "use_claim", "surfaces": ["早餐"]},
-    {"canonical": "辅食", "facet": "use_claim", "surfaces": ["辅食"]},
-    {"canonical": "炒菜", "facet": "use_claim", "surfaces": ["炒菜"]},
-    {"canonical": "商用", "facet": "use_claim", "surfaces": ["商用"]},
-    {"canonical": "加深", "facet": "shape_claim", "surfaces": ["加深"]},
-    {"canonical": "大号", "facet": "size_claim", "surfaces": ["大号"]},
-    {"canonical": "小号", "facet": "size_claim", "surfaces": ["小号"]},
-    {"canonical": "迷你", "facet": "size_claim", "surfaces": ["迷你"]},
-    {"canonical": "电磁炉", "facet": "stove_claim", "surfaces": ["电磁炉", "电磁炉适用", "电磁炉专用"]},
-    {"canonical": "燃气灶", "facet": "stove_claim", "surfaces": ["燃气灶", "煤气灶"]},
-    {"canonical": "新品", "facet": "marketing", "surfaces": ["新品", "年度新品", "新升级"]},
-    {"canonical": "官方旗舰店", "facet": "marketing", "surfaces": ["官方旗舰店", "旗舰店"]},
-    {"canonical": "正品", "facet": "marketing", "surfaces": ["正品"]},
-    {"canonical": "补贴", "facet": "marketing", "surfaces": ["补贴", "政府补贴"]}
-  ]
-}

package/skills/taobao-search-product-form/references/topics/advertiser-analysis-method.md

@@ -1,43 +0,0 @@
-# Advertiser analysis method
-
-Source class: U, confirmed by the user for this Skill's placement module. Apply the method to each input without carrying over sample-specific names, counts, thresholds, or conclusions.
-
-## Question and grains
-
-The module identifies **observed advertising-position participants** in one search export. Keep three populations distinct:
-
-1. An advertising appearance is one row in the advertising sheet. Repeated product IDs remain repeated appearances.
-2. An advertised product is one unique `商品ID` in the advertising sheet.
-3. An advertiser shop is one verified operating-shop name in the advertising sheet. Preserve each row's original `店铺名称` as its display label. A known platform display label such as `百亿补贴品牌优选` can be attributed to the actual shop when the same product ID also has an actual-shop display name and every `掌柜名` for that ID matches that actual shop. Keep the source label, resolution basis, and count of affected appearances in the evidence. Other multi-name identities stay unresolved for review; equal names do not verify a legal entity.
-
-Use the clean natural sheet as a comparison population. Join product overlap by `商品ID`; compare shops by the resolved operating-shop name when the display-label rule is corroborated, otherwise by exact `店铺名称`. Keep source display labels and any remaining cross-placement mismatch visible. Summarize shop type and similar supplied attributes as labels, not proof that a seller owns a brand.
-
-## Interpretive questions
-
-- Breadth and concentration: how many shops and unique products occupy advertising positions? How do shop-level product counts and appearance counts distribute? A sorted full table and cumulative shares let the reader choose the breadth cutoff; do not embed a fixed opportunity threshold.
-- Promotion pattern: is an observed shop represented by one product or several? Are particular products repeated in the captured advertising rows? Show both product counts and appearance counts, because one is assortment breadth and the other is only observed placement frequency.
-- Natural-position relationship: which advertised products also have a natural row, and which appear only in advertising rows in this export? Do the same exact-name check for shops. This is coexistence in a snapshot, not causal evidence that advertising improved or compensated for natural position.
-- Shop-type structure: compare the advertising and natural populations at the **same grain** (shop with shop, unique product with unique product). State the actual field label; do not convert it into a brand/white-label classification without independent evidence.
-- Advertiser merchandise layout: for each prominent advertiser in the observed ad-appearance ranking, show its advertised product IDs beside the distinct natural-position products under the same operating-shop name that it did not advertise. Compare the shop's visible natural-product count and `付款人数` sum with the natural-position records of the advertised IDs. A shop's established natural-position traction and the traction of the exact products it advertises answer different questions. Transfer a same-ID appearance into a same-shop subtotal only when its operating-shop identity is corroborated; otherwise keep the product match separate.
-- Product traction: read `付款人数` from the first-seen natural row for each product ID, never from an advertising row. For a shop, report the number of natural products alongside the sum and median of their displayed `付款人数`, because a sum grows with assortment breadth. A product with no natural row has unknown natural-position traction, not zero. The time window and whether the same payer bought several products are unspecified, so a sum is only a sum of displayed product values.
-- Price positioning: profile unique advertised products using the first advertising appearance's `现价`; preserve any alternate observed ad prices as a quality flag. Choose price-band boundaries after inspecting the current distribution, record those boundaries with the run, and apply the same intervals to the natural comparison population. Compare advertised and non-advertised products within advertiser shops as well as the full search export. The export may contain off-target listings until visual eligibility is checked, so describe this as a search-result price pattern.
-
-## Representative-shop selection and interpretation
-
-Select cases from the full advertiser-shop table, rather than choosing familiar brands in advance. Start with shops prominent by observed ad appearances or unique advertised products, then add contrasting configurations when available: advertised listings that are already prominent in natural-position payment counts; advertised listings that differ from a shop's stronger non-advertised natural listings; a narrow cluster of similar prices versus a broad price ladder; an ad-heavy shop with little natural-position coverage; and a shop whose advertised listings may fall outside the target product. Explain why each case was selected. The case count follows the variety of observed configurations, not a fixed quota. A shop with incomplete same-name natural coverage can illustrate visibility limits but not a weak-sales verdict.
-
-For each selected shop, build a compact product roster from `ad_products` and `natural_products_of_advertiser_shops`: identifiable product title cue and ID, observed ad price, ad-appearance count, natural-row `付款人数` when present, and whether the product is advertised or only in the same-name natural results. Include every advertised product when the assortment is small; show the strongest or most contrasting non-advertised natural products and state the remaining count. Compare like with like before interpreting prices or payment counts. Titles identify listings and claimed material/function, but do not prove visual form, material authenticity, or consumer need.
-
-Write three distinct layers for each case:
-
-1. **Observed layout:** what the shop puts into advertising positions; which of those products also appear naturally; which visible natural products it leaves unadvertised; where the prices and displayed payment counts sit. Describe the observable configuration (for example, promoting proven products, covering several price tiers, or advertising other products while strong natural listings remain unadvertised).
-2. **Strategy reading:** state the narrow inference this configuration permits and at least one alternative explanation or unknown when intent is material. A snapshot can show product allocation, not budget, objective, conversion, ROI, or whether the placement was the seller's deliberate long-term plan. Repeated ad rows indicate observed frequency only.
-3. **White-label implication:** translate that case into an actionable next research question or competitive boundary. Identify the exact listing/form/price comparison to inspect next, and the evidence needed before entering. An implication must follow from the case; generic exhortations or product ideas unsupported by the export add no value.
-
-Across cases, compare the observable advertising configurations and explain what they imply for the research sequence. Distinguish the areas already occupied by sellers with visible payment traction from higher-priced or ad-only listings whose demand remains unverified. A candidate opportunity needs later image-based product-form classification, reviews/consumer problems, brand dependence and supply economics; this placement module only tells the investigator where to look.
-
-## Conclusion artifact contract
-
-Write an evidence-backed narrative for later HTML use: an upfront cross-shop finding; a transparent case-selection note; a concise comparison table; substantive individual shop profiles using the three layers above; and a final cross-shop synthesis with prioritized next checks. Keep method and limitations near the relevant claims. Each case states its relevant denominator and can be reconstructed from the JSON's `advertiser_shops`, `ad_products`, `natural_products_of_advertiser_shops`, and `price_bands`. Preserve unavailable natural payments as unknown, not zero. The reader should understand which specific goods each typical shop appears to promote, how that differs from its visible unadvertised assortment, and what the contrast means for white-label research without opening the JSON.
-
-An advertising-position row does not measure spend, paid impressions, clicks, ROI or campaign duration. A single search export is not a market-wide census or time trend. Product-form and white-label entry conclusions require later image and product analysis.

package/skills/taobao-search-product-form/references/topics/geography-analysis-method.md

@@ -1,23 +0,0 @@
-# Listing-location analysis method
-
-Source classes: U for the user-confirmed research question and staged workflow; A for this diagnostic method; E for the observed input field and verifiable script results. Apply the method to each search export without carrying over one search term's region names, counts or opportunity conclusion.
-
-## Evidence unit and meaning
-
-The cleaned natural sheet supplies one first-seen row per product ID. Its `地址` is a listing-export location label. It may describe display, shipment or another platform address convention; this dataset alone cannot establish the actual dispatch warehouse, merchant registration, factory, sourcing channel or production cluster. Preserve the raw address alongside parsed province and city. Standardize whitespace and municipalities; retain unknown and unparsed values instead of guessing a city.
-
-Use three simultaneous units: unique natural product ID, exact shop name, and exact shop–address pair. A shop may appear in several addresses, so regional shop counts cannot be added into a global shop total. Identify each region's top-shop product share and within-region listing HHI to test whether an apparent cluster is broad or dominated by a few merchants. These are search-listing concentration measures, not platform market shares.
-
-## Ordered analysis questions
-
-1. **Where are the visible listings?** Count natural products, distinct shops, shop–address pairs and missing or unparsed addresses by province and city/address. Show product share, price quartiles, displayed `付款人数` median and high-payment product count. A larger listing count signals visible supply in this search snapshot, not manufacturing origin or total market scale.
-2. **What do those listings claim to be?** If a title-root artifact from the exact same cleaned workbook exists, join by product ID after verifying the workbook hash and product-title population. Cross region with materially informative root facets; keep the full root–region grid in machine output. For each cell calculate distinct products, distinct shops, within-region coverage, share of the root's products located there, and location quotient (within-region root coverage divided by corpus root coverage). Require at least ten products and three shops before treating a city–root cell as a narrative screening lead; this guard is not statistical significance. Compare the cell's top-shop share to avoid calling one seller a regional specialty. Title roots remain seller language; physical forms require image review.
-3. **What is the visible price and payment pattern?** Use the natural-position price and source `付款人数`, show medians and an all-sample 90th-percentile payment threshold. The source does not specify the payment period. For regional price comparisons, compare within the same title-root proposition and similar price quartile band where sample size permits. Product mixes, rank position and brand presence may confound differences. Never call payment people units sold, GMV or a causal response to region.
-4. **Who appears in advertising positions?** Count advertising appearances, unique advertised product IDs and exact shops separately by their observed address. Record product-ID overlap with natural positions and address differences for the same ID. Repeated ad appearances are not unique products, spend or impressions; ad-only products do not enter natural price/payment counts. Advertising geography adds competitive context, not a purchase or production signal.
-5. **What should be investigated next?** Name contrasting, evidence-backed regional cases: broad merchant participation versus single-shop concentration; title-root specialization versus generic products; meaningful natural-payment records versus listings with little visible traction; advertising-heavy versus naturally represented regions. For white-label selection, turn these into image-review and supplier-verification leads rather than a final region or product decision.
-
-## Outputs and QA
-
-Run `scripts/analyze_geography.py --input CLEANED.xlsx --output-dir NEW_DIR` and optionally `--title-roots PRODUCT_ROOTS.json` from the same workbook. It writes `geography_detail.json` (product, ad appearance, shop–address and joined root evidence) and `geography_summary.json` (region, root–region, ad-region statistics and definitions). Write a separate Markdown conclusion tracing named facts to those outputs. Register all three artifacts under `classify/geography` in the development ledger.
-
-Reconcile natural IDs and row counts to the clean sheet; verify each region's product count and shop count with independent grouping; inspect multi-address shops and blank/unparsed addresses; verify the optional root hash and product-title join; keep advertising appearances separate from distinct ad products; and sample named conclusion figures against the JSON. If the root artifact is unavailable, complete the standalone geographic analysis and explicitly leave root–region findings unavailable. Reject a mismatched root artifact rather than joining unrelated runs. Preserve approved upstream stages.

package/skills/taobao-search-product-form/references/topics/price-band-analysis-method.md

@@ -1,27 +0,0 @@
-# Sample-derived price-band analysis
-
-Source classes: U for the user-confirmed dynamic Jenks method and clean-stage eligibility boundary; E for the observed workbook and the documented Jenks algorithm; A for the declared model-complexity and interpretation policy. Apply this method anew to each search export. Never carry over a previous run's numeric boundaries or conclusions.
-
-## Population and price meaning
-
-The fitted population is every unique product ID in the cleaned `自然位` sheet. This module does not decide whether a listing is the target product: if a future search term returns multiple incompatible product types, resolve the intended population in the upstream clean stage and record that decision there. On the current flat-pan test, every cleaned natural product participates. The `广告位` sheet contains display appearances, including repeats and ad-only IDs; fit no boundaries with those rows. Map their observed prices to the natural-derived bands solely for competitive context, preserving both appearance and unique-ad-product counts.
-
-Fit `现价`, the source's displayed current price. A search result may advertise its cheapest SKU, promotion or a specification unlike another listing. `原价` is not a transaction price. The module requires positive finite current prices and unique natural IDs; fail visibly if those contracts are broken rather than silently dropping rows. Preserve all assignments by ID.
-
-## Derive bands
-
-Use one-dimensional weighted Jenks natural breaks on the logarithm of positive current prices. Repeated identical prices remain in one band. The log scale makes relative price changes comparable across low and high parts of a category; this is an analysis choice, not a universal consumer-psychology law. Optimize within-band squared log-price deviation; do not use equal-width or equal-count buckets.
-
-Evaluate feasible band counts, each with a minimum sample support of 2% (at least two products) and a maximum candidate count of ten. Start with one band and accept an additional band while its marginal explained-variance gain reaches the declared 0.03 complexity penalty. These are method parameters to be audited and adjusted during Skill development, not fixed yuan thresholds. Publish the full candidate-fit curve and the chosen count. Probe penalties 0.02/0.03/0.04 and perform reproducible bootstrap resampling; if band count or boundaries move substantially, report the result as provisional and examine the source rather than asserting a sharp market boundary. The deterministic script implements and records the exact parameters.
-
-The boundary is the first observed price in the next band. Intervals are lower-inclusive and upper-exclusive, with an open upper end for the final band. Present actual source-price min/median/max and counts so users can see how the fitted ranges relate to the listings. Avoid cosmetically rounding a fitted boundary to a familiar number unless a later, separately tested consumer-price rule supports it.
-
-## Interpret for selection
-
-For each band, compare natural product count/share, distinct shop count, observed median `付款人数`, and advertising appearance/unique-product presence under the same boundaries. A large band means many visible listings, not automatically more buyer demand. `付款人数` has no verified observation window or exposure denominator, so it is a traction clue, not conversion rate, units, GMV or estimated demand. Ads are placement evidence, not spend, auction pressure or ROI. Explain differences among bands in ordinary language, identify where follow-up SKU/price and visual-form checks would change the selection decision, and do not infer a white-label entry price from the distribution alone.
-
-## Output and QA
-
-Run `scripts/analyze_price_bands.py --input CLEANED.xlsx --output-dir NEW_DIR`. It creates `price_band_detail.json` (one product-band row per natural ID and ad-appearance rows) and `price_band_summary.json` (source hash, method, candidate models, selected boundaries, sensitivity, bootstrap stability, band metrics and reconciliations). Write a separate Markdown conclusion that can stand without the JSON and cite the actual sample figures. Register all three artifacts in the ledger under `classify/price`.
-
-Verify workbook hash, all natural IDs assigned exactly once, band counts summing to the natural population, advertising appearances summing to the ad sheet, no duplicate-price splits, and boundary intervals covering every displayed current price. Inspect the 0.02/0.03/0.04 sensitivity and bootstrap intervals before phrasing boundaries as stable. If a later visual product-form module finds materially different populations, refit the price bands only after the user approves a new upstream eligibility choice or a distinct within-form analysis; preserve this run's original result.

package/skills/taobao-search-product-form/references/topics/title-root-analysis-method.md

@@ -1,37 +0,0 @@
-# Natural-position title-root analysis
-
-Source classes: U for the user-confirmed product-to-root evidence table and exploratory statistics; A for the following analysis and dictionary-maintenance design. Apply this method to each input without carrying over one product's sample-specific counts or opportunity conclusion.
-
-## Purpose and boundary
-
-Use only the cleaned `自然位` sheet, one first-seen row per `商品ID`. The input search phrase is an observed buyer query; the words inside product titles are seller-supplied descriptions, claims and search-optimization language. Title-root coverage is therefore **not** buyer query volume. A title-stated form or material is a claim to be checked against images, product details or other evidence, not a verified physical attribute.
-
-Keep two grains: one product row per unique ID, and one product–canonical-root row per `(商品ID, facet, root)`. The latter retains original title, image URL, price, source `付款人数`, shop and every matching surface/span for convenient filtering. Product fields are duplicated only for viewability; aggregate across distinct product IDs, never by summing the entire exploded root table. A product can belong to several roots and root-level payment sums cannot be added together.
-
-## Dictionary lifecycle
-
-Use a versioned, shareable base lexicon at `references/title-lexicon.json` for phrase protection, aliases and semantic facets. A reviewed optional project lexicon may extend it. At the start of **each run**, merge these read-only lexicons, reject conflicting surface meanings, and save the exact source hashes, entries and tokenizer version in `lexicon_snapshot.json`. Do not rewrite the shared or project lexicon as a side effect of analyzing new titles.
-
-Build a fresh per-run `lexicon_candidates.json` from frequent unclassified `jieba` segments, with product and shop coverage plus example product IDs. These are candidate additions, not automatic rules. In development mode, inspect candidate phrases, segmentation examples and semantic ambiguity with the user; approved improvements may be added to a reviewed project lexicon or a later separately authorized base-lexicon version. In ordinary run mode, keep candidates in the output for later review while the existing reviewed lexicon supports a low-interaction run. Re-running with an updated lexicon produces a new output directory and records the new dictionary hash.
-
-The extractor uses a local `jieba` tokenizer for candidate segmentation, while longest protected lexicon phrases preserve domain expressions such as material and form claims. The same title may carry overlapping labels from different facets; within one facet a longer phrase takes precedence over an embedded shorter phrase. `jieba` segmentation is lexical evidence, not a trustworthy semantic category on its own. Preserve original surfaces and normalized-title character spans. Numeric sizes such as `24cm` are separately recognized as size claims. Brand and promotion words remain tagged or unclassified for audit; they are not silently removed from the source.
-
-## Statistics and interpretation
-
-For each root, calculate distinct-product coverage, shop coverage, price quartiles, median and upper-quartile displayed `付款人数`, and the fraction of products above the current dataset's 90th-percentile payment threshold. Show the actual threshold and count because ties can make the fraction differ from exactly 10%. Retain the product ID evidence and leading shops. For each shop, identify both its most common mapped roots and roots whose within-shop product coverage exceeds their corpus-wide coverage. The latter ratio is descriptive and needs a minimum of two shop products and five corpus products; it is not evidence of ad budget or intentional strategy. Show the corresponding visible-product payment values. For cross-facet root pairs, count distinct products carrying both claims; use these combinations to discover product propositions, not to assert a consumer segment.
-
-Prioritize interpretation questions over a raw frequency list:
-
-1. Which roots are nearly universal seller language and therefore weak product differentiators?
-2. Which material/structure/use combinations occupy distinct price ranges and have actual natural-position payment records?
-3. Is an apparent strong root spread across many shops, or concentrated in a few named sellers or brands?
-4. What does one shop emphasize across its assortment, and which of those listings account for its visible payment evidence?
-5. Which roots point to different possible physical forms or off-target products and need image review before comparing them?
-
-Compare roots within plausible product-form and price groups where possible. A single search snapshot does not establish growth, elasticity, advertising return or unmet demand. Source `付款人数` has an unspecified period; do not rename it sales units or GMV. An observed price/traction contrast may be explained by brand, form, assortment width, search rank or other unobserved factors. Later visual classification is the authority for actual form.
-
-## Output and QA
-
-Run `scripts/analyze_title_roots.py --input CLEANED.xlsx --output-dir NEW_DIR` with optional `--project-lexicon REVIEWED.json`. The new directory contains `product_roots.json`, `root_summary.json`, `lexicon_snapshot.json` and `lexicon_candidates.json`; then write a separate evidence-backed human conclusion for the later report. Use counts and representative product IDs from the JSON, state the selected denominator, and mark proposed product-form or demand interpretations as hypotheses pending image or buyer-search evidence.
-
-Check that the product count equals the cleaned natural sheet, every product ID is unique, each product–facet–root key appears once, price/payment values trace to the source row, and sampled long phrases, aliases, sizes and promotional words preserve expected boundaries. Inspect high-payment listings, rare forms and candidate terms manually before treating a root as a market signal. A failure of a required dependency or source field stops this module with a specific error; it must not fall back to unrecorded ad hoc segmentation.

package/skills/taobao-search-product-form/references/topics/visual-form-method.md

@@ -1,31 +0,0 @@
-# Image-grounded form judgment
-
-The upstream clean stage defines the product population. This module describes what is visible in its images; if a main object is ambiguous or appears outside the intended product boundary, flag it for that upstream decision rather than silently deleting its record. The image may disagree with a title or platform category.
-
-## One semantic read, three selection dimensions
-
-Before the first image call, create disjoint batches and record each readable product ID, image path/hash and batch ID. An original exceeding 10 MB is a `too_large` image-manifest item, retained in the natural-product evidence as `not_observed` and excluded from semantic batches and visual candidate groups; its title cannot substitute for an image observation. Record its ID and omission reason, then continue with the readable images. A visual worker receives the same questions and any provisional registry snapshot, but no closed list of allowable labels. For each ready product, capture one raw observation with `product_id`, `image_sha256`, `batch_id`, `status`, `visible_evidence`, and three independent dimensions:
-
-1. `form`: one candidate structural class, evidence and visible traits such as outline, depth, divisions, size and handle/lid relationship. Assign `uncertain` if the structure cannot be resolved. Color alone never splits a structural class.
-2. `style`: optional candidate product-design style, at least two concrete product-side cues, and a possible physical design delta. Keep main-image background, copy, lighting and graphic treatment in a separate `image_presentation` note. A style name derived only from one color is too weak and remains a cue rather than an accepted style class. Leave style unclassified when the product is visually generic or obscured.
-3. `audience`: optional candidate group defined by a use task, visible task cues, an explicit evidence tier (`image_only`, `combined`, or `insufficient`), and a plausible product-side adaptation. A depicted egg is a task cue, not proof of the buyer's demographics or actual purchase behavior. A candidate audience requires a task that could change the product's size, structure, handling, set configuration or design. If there is no such evidence, leave it unclassified. Any later title/price corroboration is recorded as a separate join, not retroactively presented as image evidence.
-
-The three dimensions are parallel selection paths. A style-led or audience-led physical product difference can constitute a new candidate merchandise proposition even when its base structural form matches another product. Distinguish candidate proposition from demonstrated opportunity: a single search snapshot cannot prove demand, profit or actual buyer identity.
-
-Inspect each original cached image independently, working through small checkpoint batches. The contact sheet is an orientation and coverage-audit artifact, not the sole semantic input. Save each completed batch as an immutable, plan-bound checkpoint before moving on, and use the batch status command to resume after a context boundary. Every product remains independently keyed; the batch draft uses `{"schema_version":2,"observations":[{"product_id":"…","status":"tagged|uncertain","visible_evidence":"…","form":{"candidate":"…"},"style":{"candidate":null},"audience":{"candidate":null}}]}` with the evidence fields above when style or audience is proposed. The checkpoint command binds each row to its planned image hash and rejects missing or extra IDs. Reopening an unclear original is a QA exception to the single-pass aspiration; log it. Use bounded concurrent semantic workers or multi-image calls only when the host actually supports independent per-image understanding and their outputs can be reconciled; each worker owns disjoint product IDs. Unverified acceleration never blocks the serial path, and image-download concurrency does not count as semantic concurrency.
-
-## Product-style prototype convergence after the image reads
-
-The three raw observation dimensions are useful evidence, but the final classification answers a different question: **what distinguishable merchandise styles can the seller actually choose, compare, source or develop?** A prototype is a coherent real-product scheme described through several jointly visible cues: base object, construction and handling, key functional configuration, and (when material to selection) an integrated product-design language. A single feature count—body silhouette, lid, spout, color, surface texture or photographed food—is not itself a complete style. A prototype name should let a merchant picture the actual good, such as “锤纹雪平锅” or “蒸煮一体小锅”, without requiring the source title to complete its meaning.
-
-1. Start with a varied image sample rather than a fixed category dictionary. Sketch candidate prototypes with a physical definition, sourceable selection difference, representative product IDs, inclusion and confusion boundaries. Use the original images and saved visible observations. The prototype registry is run-specific and can grow as new physical schemes appear.
-2. Compare each later product with representative and boundary images. Assign it to an existing prototype when differences are ordinary size, color or selectable configuration variants. Create a new prototype when the whole structure, function set or distinctive finished-product design demands a different comparison or supplier-development task. Revisit earlier near neighbors after a new prototype is introduced. A real rare prototype remains visible with its small count.
-3. A main image containing multiple recognizable goods can associate its listing with multiple prototypes; a hybrid good can likewise support more than one selection-relevant proposition. Preserve the product ID once in the population and record every justified membership. Keep ordinary variant details and single visual cues in separate fields so groups stay interpretable. Image presentation, graphic copy, inferred material, buyer demographic and unsupported use claims cannot create a prototype.
-4. Keep out-of-object accessories, image-only promotional compositions, unresolved objects and unreadable images in explicit boundary/uncertain states. Do not silently delete their product IDs. Class membership is image-grounded; title, price, payment or shop data cannot decide the visual class.
-5. Review group cohesion with representative, edge and low-confidence images, then compare near-neighbor groups for missed same-style merges. A group is useful when its members look like a coherent sellable product line and its distinction from another group would change the next selection investigation. Record merge/split reasons and remaining uncertainty; a smaller class count alone is not proof of quality.
-
-Keep the raw observations immutable. A classification pass writes a versioned registry plus one decision for every planned ready product: `product_id`, `image_sha256`, `style_ids` (one or more), `variant_or_features`, `reason`, `confidence`, and optional `boundary_reason`. The registry records `style_id`, name, physical definition, selection difference, inclusion/boundary rule and representative IDs. The deterministic `compile_style_prototypes.py` validates this decision file against the original plan and observations, then outputs product-level labels, prototype summary and an audit. Re-aggregation may reuse the saved image-hash-bound observations; reopen an original when its description does not settle a consequential boundary. New product images still require their own semantic observation.
-
-Use prototype groups in downstream joins and report navigation. Preserve structural form, design style and use-task observations as secondary evidence and filters. Reconcile `ready = observed = style-decided` and `too_large = not_observed` before full-run reporting; other unavailable-image reasons require diagnosis or retry. Count distinct product IDs for population and demand comparisons because prototype memberships can overlap. Join price, natural payment counts, shops and advertising only after the visual classes are finalized. This stage describes visible supply options, not buyer demand or entry feasibility. Return to Main Line Step 4 after this gate.
-
-This phase describes visual supply, not buyer demand or product-entry feasibility. Join title roots, price, placement and other evidence in later modules before recommending a form.

package/skills/taobao-search-product-form/references/topics/white-label-evidence.md

@@ -1,38 +0,0 @@
-# From product observations to opportunity cards
-
-## Question and candidate grain
-
-The goal is to help a user decide what to research next, not to declare that a product can or cannot be sold. Begin with the image-grounded **whole-product style prototypes**: each is a coherent, sourceable merchandise option. Structural form, product-design cues and image-supported use tasks explain why a prototype is distinct and provide optional comparison cuts; a task becomes meaningful only when it implies a physical product difference, not merely new copy or a hero-image theme. An image-supported use task is not a verified buyer demographic.
-
-Compare each prototype against its closest real-product alternatives and, where useful, the broader structural parent. Form–style and form–task intersections are secondary cuts when their member IDs and shop spread support interpretation. Candidate groups overlap, including listings that display more than one product style; their counts cannot be summed. Do not impose a permanent minimum count across categories. For sparse groups, report the observed products and roll the commercial comparison back to a better-supported comparable group. An unclassified task means insufficient image evidence, not absence of task demand. Preserve uncertain/non-target products outside candidate traction calculations until their boundary is reviewed.
-
-## Five evidence questions
-
-1. **Observed traction.** Examine distinct natural products and shops, the distribution of displayed `付款人数`, representative high-payment and ordinary products, and whether the group's apparent strength survives removal of its leading shop or product. A sum across product records is a descriptive index, not distinct buyers, monthly sales, units, conversion or GMV. A single search export cannot establish a growth trend or full-market share.
-2. **Comparable price structure.** Use the run's fitted price bands to locate supply, then compare like products within the same structure and the closest observable configuration. Report price median and spread, not only an average. Search-page current price may select a different SKU or discount; a higher displayed price is not proven willingness to pay or margin.
-3. **Merchant-line configuration.** For representative shops, contrast the candidate products with the same shop's other visible forms, versions and price tiers; identify natural-position strong products separately from products appearing in advertising positions. Describe the observed assortment. SKU roles, intentional product strategy and brand ownership remain hypotheses until separately verified. A multi-shop pattern has different implications from a group carried mainly by one shop.
-4. **Competitive exposure.** Keep ad appearances, distinct ad products and distinct advertiser shops separate. Connect natural products to ads by product ID and exact shop name; preserve cross-shop name conflicts and ad-only products as unknown-form or unknown-payment cases. Advertising can indicate both seller attention and acquisition pressure; it does not measure spend, exposure or ROI.
-5. **Product-side opening.** State which visible structural, material-appearance, color-system, handle, size or task-fit variation could make the proposed product different. Check whether existing merchants already cover it. Title roots are seller claims and discovery clues; image labels are visible observations; reviews, specifications, supplier quotes and tests are needed to establish user benefit, material truth, manufacturability and defects. Listing address may guide sourcing questions but does not identify a factory.
-
-Compare competing explanations explicitly. For example, a candidate may show high displayed payment because of one established shop, a lower price, stronger natural ranking, a different underlying product configuration, or multiple shops independently selling it. Where the current export cannot distinguish these, present the alternatives and the discriminating next check. Do not smooth contradictions into an opaque score or infer that low ad presence means low competition.
-
-## Opportunity-card contract
-
-Create `opportunity_cards.json` with `schema_version: 2`, `source_evidence_sha256` (the current comparison JSON file's exact SHA-256), selected strategy/version and an array of cards. Each card's `candidate_id` resolves to a `product_style` candidate. Secondary form/style/task candidate IDs may appear as evidence references or comparison context. A readable Markdown rendering carries the same content.
-
-| Field | Required meaning |
-| --- | --- |
-| `candidate_id`, `definition`, `parent_comparison` | Exact whole-product style member set and concrete product-side proposition, with the closest comparable prototype or broader structural form used for context. |
-| `scope` | Source population, tagged/uncertain coverage, member product/shop counts, missing modules and search-snapshot limitations. |
-| `observations` | Numeric traction, price, merchant-line, advertising, title and location facts, each linked to the compare artifact's field or product IDs. |
-| `supporting_evidence`, `counterevidence` | Separate, traceable items; an empty side must say evidence is unavailable, not imply proof. |
-| `interpretation` | A bounded explanation that considers shop, price and product-configuration alternatives. |
-| `unknowns` | Missing facts that could reverse the current research priority. |
-| `next_checks` | Specific review, SKU/price, cost, supplier or small-test questions; indicate what result would change the judgment. |
-| `research_order` | Optional reasoned research sequence relative to other cards, never a binary market-entry decision or composite score. |
-
-Every card should be readable without opening the raw JSON, while every named number and shop claim must trace back to the compare artifact. Keep observation, inference and proposed test visibly distinct. Include at least one representative product and one ordinary or counterexample product when available; show if the sample is too small for that comparison. The cards are complete when the user can inspect both the reason to investigate and the strongest reason that it may be misleading.
-
-## Handoff boundary
-
-The card may suggest a profit calculation or supplier investigation because those checks resolve uncertainty. It cannot conclude net margin, a verified unmet need, factory access, or an entry decision from a search snapshot. The broader product-development method separates demand, product differentiation, net profit, supplier standards and low-risk testing. Defer the last three to their own evidence-gathering stages; do not represent a request for research as authorization to buy, stock or publish.

package/skills/taobao-search-product-form/references/workflow-ledger.md

@@ -1,28 +0,0 @@
-# Stage ledger
-
-The per-run `ledger.json` lives beside that run's data, not inside this Skill. It records two independent dimensions: `design_state` (`open`, `defined`, `validated`) describes how mature the stage method is; `status` describes what happened in this particular run. A stage can have a defined method without having been executed, or a provisional result awaiting review.
-
-The initial stages are `input`, `clean`, `classify`, `compare`, `decide`, and `report`. Add a classification module with a stage ID such as `classify/placement` or `classify/visual-form` when that module is selected. These IDs are navigation handles, not a declaration of the module's eventual field schema or algorithm.
-
-Statuses:
-
-- `not_started`: no current result.
-- `in_progress`: work begun, with intermediate artifacts if any.
-- `awaiting_review`: development result exists and awaits the user's review.
-- `approved`: the user confirmed the development result; record reviewer and what was approved.
-- `verified`: run-mode result passed its automatic QA.
-- `blocked`: cannot safely advance; record the reason.
-- `skipped`: reserved for a documented development-stage experiment outside the complete run; record why when it could be mistaken for missing work.
-
-Commands (resolve the script relative to the Skill directory):
-
-```text
-python3 scripts/workflow_ledger.py init --run-dir RUN_DIR --mode development --input WORKBOOK
-python3 scripts/workflow_ledger.py show --ledger RUN_DIR/ledger.json
-python3 scripts/workflow_ledger.py record --ledger RUN_DIR/ledger.json --stage clean --status awaiting_review --artifact OUTPUT_FILE --note "What was checked and what remains for review"
-python3 scripts/workflow_ledger.py record --ledger RUN_DIR/ledger.json --stage clean --status approved --reviewer USER --note "What the user confirmed"
-```
-
-`record` also accepts `--design-state`, `--strategy` and repeated `--artifact`. Artifact paths are resolved to existing files and stored with size and SHA-256 so later work can detect changed inputs or intermediates. Each update adds an event and creates a recoverable backup of the previous ledger. `init` refuses to replace an existing ledger.
-
-In development mode, a stage may be reviewed and approved independently while the complete workflow is being built. The next stage reads its actual approved artifacts and ledger scope. Record parent and downstream stages when their artifacts are produced; approval of a report does not automatically approve each source stage. If an input or strategy change makes a downstream result stale, mark that downstream stage accordingly with a reason before reusing it. In run mode, execute every required stage and module, update the ledger after each material transition, and continue after automated verification without routine user review. A development-stage review may stop after its current module and hand off the ledger plus artifacts.

package/skills/taobao-search-product-form/report_runtime/VERSION

@@ -1 +0,0 @@
-1.2.5