DTC Daily Ops Router

1. One router, deterministic execution and a review queue

The natural-language skill is only the entry and routing contract. Scheduling, run locks, retries, hashing, schema validation, baseline pointers and file output belong in a deterministic runner. Platform-specific access stays inside connectors, and every real external write remains outside the daily collection job.

QoderWork CN schedule / command
  -> dtc-daily-ops-router
  -> deterministic daily runner
  -> tenant + seat policy / credit guard
  -> SellerSprite + owned + competitor connectors
  -> SignalEvent + AuditEvent evidence ledgers
  -> ProductCandidate auto-selection
  -> MultimodalOutreachPack per creator
  -> DingTalk selection brief / Feishu outreach queue
  -> credit ledger + delivery receipt + read-back

The product is not “more scraping.” The product is a daily, evidence-linked decision record that makes missing coverage visible.

2. Eight modules with separate responsibilities

3. Eight gates that every daily run must pass

4. Public competitor signals and owned metrics are different products

The source contract distinguishes owned_authorized, competitor_official_public, public_observation and inferred. A number never moves between these scopes without retaining its original definition.

Commerce truth rule: Shopify is the transaction ledger for owned orders, refunds and inventory. GA4 and each advertising platform keep their own attribution basis and maturity state; attributed conversions are not added together as store orders.

5. Five operating contracts, one access policy and two governance ledgers

observed evidence
  -> explicit interpretation
  -> proposed action
  -> pending_human_review
  -> approved operator execution
  -> read-back verification

6. No-manual product selection and evidence-led creator activation

The current operating route uses QoderWork CN as the orchestrator, SellerSprite as an authorized product, keyword and review evidence source, DingTalk CLI as the internal selection-delivery surface, and Feishu CLI as the batch creator-work queue. “No manual selection” means the daily run does not rely on a person browsing products and picking favorites; administrators own the policy and hard thresholds, while the runner makes the candidate decision deterministically.

QoderWork CN
  -> SellerSprite evidence snapshot
  -> ProductCandidate hard gates + ranking
  -> AUTO_SELECTED / REJECTED_HARD_GATE / NEEDS_FRESH_DATA
  -> DingTalk CLI selection brief

Creator evidence + Product Truth Card
  -> MultimodalOutreachPack
  -> Feishu CLI batch work queue
  -> approved external channel
  -> delivery / reply / follow-up read-back

Automation boundary: there is no manual SKU picking inside the daily selection run, but procurement, samples, supplier outreach, Listing publication and advertising spend remain separate approved actions. Creator research and multimodal package generation can run in batch; outbound contact requires an approved roster, lawful contact basis, channel policy, rate limits and suppression handling. Tool access and connector methods must be verified per deployment.

ChatGPT referral and GEO loop: validated ChatGPT sessions and orders become demand evidence for query coverage and product selection; Product Truth then keeps the PDP, structured data, feeds and creator packs aligned. See the detailed ChatGPT Commerce GEO method for attribution states, crawl controls, feed freshness, experiments and conversion-quality measurement.

7. Enterprise teams need a control plane, not shared credentials

Enterprise access is evaluated per tenant, acting seat, assigned store, connector, action and validity period. Effective access is the narrowest intersection of role, store assignment, connector scope, approval policy, credit budget and time window—not whatever a logged-in browser happens to expose.

Tenant Admin connects store
  -> server-side credential reference
  -> seat receives scoped AccessGrant
  -> tenant + store + role + action + credit check
  -> approval when required
  -> AuditEvent + CreditLedgerEntry
  -> read-back verification or explicit revoke state

Enterprise status boundary: these are implementation requirements, not a claim that seat enforcement, complete audit coverage, ZiNiao or other managed-browser security, credit allocation or automatic offboarding is already deployed. This system cannot guarantee the security of a third-party browser. Audit coverage includes only activity this system observes or initiates; direct platform activity depends on each platform's own logs. Credit limits govern this system's credits, not advertising spend or third-party fees. Revocation is complete only after every connected system confirms it.

8. The daily brief should take five minutes to read

1. Owned-store red lights: page, checkout, inventory, tracking or connector failures that need attention first.
2. Top external movements: the most relevant storefront, social, media and public-ad changes.
3. Owned performance context: store-truth outcomes and platform metrics with attribution and maturity labels.
4. Review and search gaps: new recurring customer language connected to an owned search term, PDP or Listing hypothesis—not an automatic rewrite.
5. At most three actions: fix, test or keep watching—with owner, evidence and acceptance metric.
6. Team-control exceptions: role or seat changes, expiring grants, blocked scope attempts, privileged operations, credit use against assigned caps and pending revocations.
7. Data boundaries: sources that were blocked, stale, unsupported or not configured.

If successful coverage is zero, the report becomes an access-limited operating alert. It must not recycle historical signals into a new competitor conclusion.

9. Read-only collection first; execution requires approval

• Automatically allowed: permitted reading, snapshots, hashing, normalization, comparison, calculations, local reports and alerts to a pre-approved destination—only within the acting seat's tenant, store and source scopes.
• Human approval required: changes to storefronts, prices, inventory, content, advertising budgets, bids, targeting, campaign state, outreach or publishing. Operator, approver and read-back outcome enter the audit trail.
• No credential sharing: seats cannot view, export or reuse another seat's password, token, cookie or browser session. Possession of a browser profile does not grant store authority.
• No hidden credit spend: paid work is charged to an approved seat, store or project cap. Reaching the limit stops the paid step or requests administrator approval; it never triggers a silent purchase.
• No blind outreach or identity fabrication: batch creator work must deduplicate contacts, respect rate limits and suppression lists, and preserve review before send. Multimodal personalization may adapt a truthful SKU story to a creator's public audience context; it cannot clone a creator's face or voice, claim a past partnership or invent product use.
• No access-control bypass: no login-wall, CAPTCHA, private-account, robots or platform-rate-limit circumvention.
• No competitor result invention: ad duration, likes or creative repetition do not prove spend, sales, conversion, profitability or winning creative.
• Current status: this page is a reviewed design specification. It does not claim that every listed API connector, scheduled job or delivery integration is already deployed.

Primary platform references

• YouTube Data API — Channels
• Meta — Instagram Business Discovery
• Meta Ad Library
• TikTok Commercial Content API
• Google Ads Transparency Center
• Shopify Admin GraphQL — Orders
• GA4 — Reporting data expectations
• Google Search Console — Performance data