Soumission aux annuaires de produits IA

# AI Product Registry Submission

Build a verified product kit, discover 5 to 10 eligible AI product registries, create a centralized campaign sheet, and execute approved submissions with one independently recoverable row per registry.

## Loadout capabilities

TinyFish is required for product-source discovery and enrichment as well as registry discovery, qualification, duplicate checking, authentication preflight, and registry browser work. Use <action-tag>api:tinyfish_api:search</action-tag> to identify official product sources, discover candidate registries, and find current public evidence. Use <action-tag>api:tinyfish_api:fetch_urls</action-tag> to fetch the exact official website and relevant same-site pages, then verify product facts, current audiences, submission routes, requirements, pricing, eligibility rules, and duplicates. Do not substitute another public-web search, scraping, crawling, fetching, or browser provider.

Before browser preflight, verify that the user has connected and selected a personal TinyFish credential for the current Action call. Without a selected personal credential, Search and Fetch remain available but Agent, browser, profile, usage, and account Actions are intentionally hidden. Ask the user to connect or select their personal TinyFish account before continuing browser qualification; do not substitute another browser provider.

Use <action-tag>api:tinyfish_api:run_async</action-tag> for read-only preflight and approved submissions, then poll <action-tag>api:tinyfish_api:get_run_by_id</action-tag> until the provider reaches a terminal state. Use <action-tag>api:tinyfish_api:cancel_run_by_id</action-tag> when an asynchronous run must be abandoned. Do not set `agent_config.mode` to `strict` or set `max_steps` unless the user has confirmed the corresponding TinyFish beta entitlement; use `default` mode or omit `agent_config`.

Use <action-tag>api:tinyfish_api:list_browser_context_profiles</action-tag> to find an existing persistent profile. When authentication or a native user handoff is required and no suitable profile exists, create one with <action-tag>api:tinyfish_api:create_browser_context_profile</action-tag>, open a protected setup session with <action-tag>api:tinyfish_api:create_browser_context_profile_setup_session</action-tag>, keep that same setup session active while the user completes login, email or SMS verification, MFA, or a human check, and save it with <action-tag>api:tinyfish_api:save_browser_context_profile_setup_session</action-tag>. Attach the resulting profile to later TinyFish runs with `use_profile: true` and its `profile_id`. Cancel an abandoned setup session with <action-tag>api:tinyfish_api:cancel_browser_context_profile_setup_session</action-tag>. Never put setup URLs, CDP URLs, session IDs, cookies, or storage state in the sheet or ordinary chat.

For a native handoff, start the setup session at the exact registry page and open the returned user-facing stream URL exactly as returned. Do not derive a URL from a raw host, CDP endpoint, or inspector address. Before asking the user to act, verify that the stream renders the intended registry page rather than a blank page or browser error, and state the remaining session window. If the stream is blank or shows a tunnel failure, cancel it immediately, retry once with a supported country egress only when the site needs it, and otherwise replace the candidate. Do not ask the user to refresh broken sessions repeatedly.

Create the campaign in the sheet service selected by the user. Supported choices are <integration-tag>composio:googlesheets_tools</integration-tag>, <integration-tag>composio:airtable_tools</integration-tag>, <integration-tag>cli:lark</integration-tag>, and <integration-tag>composio:excel_tools</integration-tag>.

## Required outcome

Complete setup, build the Product Kit, discover and verify candidates, and write 5 to 10 confirmed-eligible, submission-ready registry rows to the selected sheet. Do not add rejected, uncertain, inactive, duplicate, OAuth-only, or otherwise ineligible candidates to the sheet. Never pad the sheet to reach five rows; if fewer than five can be verified, explain the shortfall and ask whether to broaden the audience or geography.

After the sheet is ready, the user can approve a specific batch for live submission. Keep every registry independent so one blocked row does not stop another eligible row.

## Source-first setup

Ask one compact setup message and wait for the answer. Request only:

- the sheet destination: "Which sheet service should I use: Google Sheets, Airtable, Lark Sheets, or Microsoft Excel?"; and
- one product source: "Please share the official website URL. If there is no official website, share another reliable source such as product documentation, an app-store page, a repository, a launch page, an existing listing, a deck, or a short product description."

Do not ask the user to fill the Product Kit field by field at the start. Identify the product and draft those fields from the supplied source and current public evidence. If the product is not unambiguous from the source, ask one targeted disambiguation question instead of a general questionnaire.

Confirm the selected sheet integration is connected before writing. If it is not connected, ask the user to connect it and preserve the supplied product source so setup can resume without repetition.

## Self-identify the product

If the user provides an official website, fetch the exact public URL first with <action-tag>api:tinyfish_api:fetch_urls</action-tag>. Extract public facts needed for the Product Kit, such as the product name, tagline, descriptions, features, use cases, audience, category, pricing, availability, regions, languages, company name, logo, screenshots, social links, and privacy or terms URLs.

Follow same-site links only when needed to fill a missing field, prioritizing About, Pricing, Product, Documentation, Security, Privacy, and Terms pages. Use <action-tag>api:tinyfish_api:search</action-tag> to find additional current public evidence and <action-tag>api:tinyfish_api:fetch_urls</action-tag> to verify it and resolve registry-relevant gaps. Record source URLs in the Product Kit notes. Do not overwrite a user-provided fact when public evidence conflicts with it; surface only the conflict and ask which value is authoritative.

If the user provides another kind of source, identify the product from that material and use TinyFish to find its current public product pages. If the user supplies only a short description, treat it as authoritative and research only the public details that can be matched unambiguously.

Build the most complete truthful Product Kit possible before asking more questions. Draft short, medium, and long descriptions from sourced facts. Leave optional unknowns blank and label inferred copy `Needs Review`. Present the completed draft for review, then ask one consolidated follow-up containing only unresolved facts that are required for eligibility or submission. Never repeat a question whose answer was established from the supplied source.

When registry preflight reveals a missing reusable fact, such as the contact person's first name, last name, title, or another non-sensitive listing field, ask one targeted question that names the affected registry or registries. Save the user's answer in the `Product Kit` tab before using it, then remap every affected registry row from that centralized value. Do not store passwords, verification codes, recovery information, or other secrets in the Product Kit.

Use safe defaults until the user approves a batch: consider free listings only, do not create accounts, do not accept registry terms, do not purchase anything, and do not submit forms. Ask about spend, account creation, terms acceptance, contact identity, email codes, MFA, or CAPTCHA only when a verified eligible registry actually requires that decision.

## Build the centralized sheet

Read [campaign-sheet.md](references/campaign-sheet.md) and create two tabs named `Product Kit` and `Registries`. Use friendly title-case field names, not internal identifiers. Do not add campaign IDs, authorization metadata, or sheet-version metadata. Center-align values and headers, freeze header rows, enable wrapping, and make URLs clickable.

Write the self-identified Product Kit before discovery so all later research and submissions use one source of truth. Mark drafted descriptions `Needs Review` until the user confirms them.

## Discover and qualify registries

Read [eligibility.md](references/eligibility.md). Always use TinyFish to search broadly enough to identify more candidates than needed, verify every candidate from current source pages, and check for existing or pending listings.

For each candidate, start a read-only TinyFish asynchronous browser preflight, poll it to a terminal provider status, and confirm all of the following before adding it to the sheet:

1. Its audience is relevant to this product and it accepts this product type.
2. A current, usable submission, add-product, vendor, or claim route exists.
3. Geography, language, availability, company, launch-stage, and domain or email rules are satisfied.
4. Required assets and fields can be supplied truthfully from the Product Kit.
5. Pricing, reciprocal-link requirements, review process, authentication, and submission terms are understood.
6. If authentication is required, the registry offers at least one feasible non-OAuth route: an email or SMS one-time code or magic link, or a standard email/username-and-password account. A registry may also offer OAuth, but OAuth cannot be its only usable route.
7. The user controls the email inbox or phone needed for verification, or a standard password flow can be completed through an approved credential boundary and the same persistent TinyFish session.
8. No existing listing or pending submission makes the row a duplicate.
9. Publication and continued listing do not require votes, social promotion, referrals, community engagement, a later payment, or another material post-submission obligation.

Exclude OAuth-only or SSO-only registries, including routes that require Google, Apple, Microsoft, GitHub, or another identity provider with no permitted fallback. Also exclude any candidate whose form, required fields, authentication route, verification destination, duplicate state, or human-handoff path could not be confirmed during preflight. A native CAPTCHA or human check is acceptable only when the user can complete it in the same persistent TinyFish session; never bypass it.

If a candidate would otherwise qualify but one ordinary user-supplied fact is missing, keep it out of the confirmed-eligible set, ask for that fact, save the answer to the Product Kit, and rerun its preflight. Do not weaken the eligibility gate or write a speculative row just to reach five registries.

Add only confirmed-eligible rows. Keep rejection evidence outside the campaign sheet and summarize excluded-candidate counts without naming them unless the user asks for the research log.

Stop when the sheet contains 5 to 10 eligible registries. Prefer the most relevant and reputable options rather than the easiest forms.

Use a fast qualification funnel. Search and fetch enough candidates to maintain a replacement queue, reject obvious duplicates, paid-only routes, forced marketing, reciprocal-link requirements, OAuth-only routes, inactive sites, and mandatory promotion before launching browser runs, then preflight the strongest candidates in parallel. Do not let one weak candidate block the set. Give each candidate one terminal browser preflight and at most one profile or egress recovery during initial qualification. If it still stalls, cannot render, or has unclear authentication, cancel it and move to the next candidate. A candidate is `Ready` only after a terminal preflight; a running, queued, expired, blank, tunnel-failed, or unresolved handoff does not count toward the 5 to 10.

## Prepare listing content

For every eligible row, map the registry's required fields to the centralized Product Kit. Reuse approved product facts and adapt only length, formatting, and category selection. Preserve exact product-name spelling and factual meaning.

Never invent founders, customers, traction, awards, launch dates, addresses, pricing, legal claims, or ownership. Leave optional unknowns blank. If a required fact is missing, keep the row out of the approved submission batch until the user supplies it.

## Launch submissions

Read [submission-execution.md](references/submission-execution.md). Show the user the exact rows, costs, account-creation requirements, verification requirements, and terms involved, then obtain one explicit approval for that specific batch. Separate approval is required for any payment, reciprocal link, domain change, claim of an existing listing, or materially different terms.

When subagents are available, assign one subagent to each approved row. Each subagent owns only that registry and must read the centralized Product Kit, the row, and the execution rules before acting. If subagents are unavailable, process rows sequentially with the same isolation.

Run every registry browser interaction with TinyFish. Start one asynchronous TinyFish run per approved registry row so rows remain independently recoverable, and poll each run by ID instead of treating a client timeout as a provider failure. Use a Browser Context Profile for login, registration, email-code, SMS-code, MFA, or user-handoff flows. Keep the same protected profile setup session active while waiting for the user, save it after the native step succeeds, and attach that profile to the row's later runs. Never assume another browser, profile, account, or agent shares its cookies.

Before triggering an email or SMS verification, confirm that the user is present and controls the exact delivery destination. For email magic links, keep the original setup session open and have the user open the inbox and consume the link inside that same TinyFish browser context; PKCE-bound links can fail if moved to another browser, saved profile, or replacement session. Do not ask the user to paste a magic link or verification code into ordinary chat. Save the profile only after the registry confirms authentication.

Use only the non-OAuth route verified during qualification. If execution reveals that the route is OAuth-only, inaccessible, or materially different from preflight, stop before account creation, remove the row from the approved batch, and record it as a qualification failure rather than attempting another identity provider.

If execution reveals a missing non-sensitive Product Kit fact, mark the row `Blocked`, explain exactly what is missing, and ask one targeted question. After the user answers, save the value in the Product Kit, update the row's mapped listing content, and resume only if the original batch approval still covers the same identity, cost, terms, and final actions.

Do not bypass CAPTCHA, MFA, security keys, passkeys, payment confirmation, or other native safeguards. Ask the user to complete the native step when required. Do not place passwords, OTPs, recovery codes, cookies, or magic links in the sheet.

Treat the final submission control as non-idempotent. If the registry has no durable draft, dashboard, or idempotency protection and an autonomous browser agent could retry the final control, use TinyFish to reach the final review state, then hand the single final click to the user in the verified protected session. After that click, inspect provider state once. Never instruct an autonomous run to retry a final submission control.

## Update each row from evidence

Update the row immediately after every meaningful transition. Use only these status values after execution starts:

- `Submitted`: the registry returned reliable submission confirmation.
- `Pending`: the registry accepted the submission but review, publication, or email verification remains outstanding.
- `Blocked`: progress cannot continue without missing data, authentication, verification, payment approval, or a site-side fix.
- `Follow-Up Required`: a dated next action is known.

Do not mark a row Submitted because a form was filled, an account was created, a button was clicked, or a browser reached a generic thank-you page. Capture the confirmation URL or exact non-sensitive evidence. If the final action has an ambiguous outcome, do not retry it; set `Follow-Up Required`, document the ambiguity, and check the vendor dashboard, mailbox, and public listing before another attempt.

If TinyFish times out or loses browser connectivity, record the last confirmed URL, completed step, whether any consequential button was clicked, and whether provider-side confirmation exists. Cost or billing status is not submission evidence. Do not retry an ambiguous final action until provider-side state is reconciled.

Close each persistent browser session after saving a terminal or recoverable row state. Report row-level totals and distinguish Submitted from publicly listed.

When any approved row fails, becomes ineligible, is found to be a duplicate, or remains blocked after recovery, tell the user which rows failed, why, what was and was not submitted, and the available recovery action. Ask whether the user wants those rows removed from the `Registries` tab and replaced through a fresh TinyFish discovery and preflight pass. Do not delete rows or add replacements without that direction. If the user approves replacement, preserve a concise failure summary before removal, then add only newly confirmed-eligible rows.

## Completion checklist

- The user selected and connected a sheet service.
- The user supplied an official website or another reliable product source instead of completing an upfront field-by-field questionnaire.
- The Product Kit is centralized, friendly, reviewable, and contains no campaign metadata.
- Website-derived facts are sourced and do not silently override user answers.
- TinyFish was used for registry discovery, verification, duplicate checks, and registry browser execution.
- The Registries tab contains 5 to 10 entries, all confirmed eligible.
- Every included registry passed a read-only TinyFish preflight and has a usable non-OAuth path when authentication is required.
- Every included registry has no mandatory voting, promotion, referral, or other material post-submission campaign requirement.
- Every row includes the current submission URL, requirements, pricing, review process, and authentication method.
- No rejected, uncertain, duplicate, inactive, OAuth-only, or otherwise ineligible candidate appears in the sheet.
- Listing content maps back to verified Product Kit facts.
- Live submissions occur only after exact batch approval.
- Every attempted row has evidence-backed status and a recoverable next step.
- Missing reusable listing facts are saved in the Product Kit after the user answers, never only in one registry row.
- Failed, duplicate, ineligible, or persistently blocked rows are reported with a remove-and-replace choice.