--- name: add-platform-source description: Add, repair, or validate an OpenBiliClaw platform source across fetching, account signals, discovery, and user surfaces. Use for source-specific integration work and its acceptance; exclude unrelated UI, recommendation-algorithm, or release-only work. --- # Add Platform Source Deliver the requested source capability through the actual product path. Use `docs/platform-source-integration.md` as the shared guide and `docs/platform-source-history-lessons.md` to find failure precedents. Paths below are relative to the repository root. Historical sessions and plans are evidence, not current instructions or proof that a missing capability is still missing. ## Select the scope and reading Declare `full`, `discovery-only`, `capability-increment`, or `audit-only`. Plain “add a source” means `full`; a repair stays within the affected capability. Research/audit does not authorize implementation. Updating this skill requires documentation and skill validation, not a new platform contract or live account E2E. Read the guide's execution protocol and completion criteria, then select the relevant sections: | Work | Guide sections and useful precedents | | --- | --- | | New source | §0 contract, §1 upstream spike, registration map; select the remaining sections by capability | | Auth / identity / settings | §0.1–0.7, §4–5; Bangumi/GitHub optional credentials, V2EX/Linux.do/Weibo capability readiness | | Browser tasks / account signals | §2–3, §5; staged completion, MV3 recovery, incremental opt-in and task isolation | | API / Feed / discovery | §1, §6–6.5; GitHub pagination/cooldown, keyword dual-track, shared admission | | Cards / native save | §7–9; DTO-to-renderer evidence, exact identity and persisted save confirmation | | Validation / delivery | §8–11; scoped tests, installed artifact provenance, separate E2E chains and documentation | For full integration, scan the whole guide's capability headings for omissions. For a narrow repair, expand to adjacent sections only when the diff crosses those boundaries; do not reopen unrelated platform implementations. ## Execute with evidence 1. Preserve existing changes and use the repository's worktree rule for implementation. Record the baseline. Before tests or E2E, prove Python imports, CLI, backend config/data roots and any installed extension resolve to the intended checkout; reload alone does not deploy a worktree build. 2. Start with the relevant history-index rows, then inspect first integration and follow-up repairs in `git log --all` and current tests. Read available project sessions/PRs only to fill a concrete evidence gap. Distinguish root user requests from delegated reviews, and merged fixes from in-flight branches. Never copy credentials, private account data, raw transcripts, or historical authorization into the task. 3. For a new source, copy the contract and acceptance templates. For an increment, reuse/update its contract and record the changed gates. Keep applicability (`required` or `N/A`, with evidence) separate from execution (`PASS`, `FAIL`, `NOT_RUN`, or `BLOCKED`). Capability exclusions need executable proof where enforceable; out-of-scope mutations need scope evidence. `deferred` and missing E2E are never `N/A`. 4. Probe the changed upstream path read-only before inventing fixtures. Preserve redacted success, pagination/termination and counterexamples. Anonymous success does not prove authenticated pagination, current-account ownership, private bootstrap, or the installed dispatcher. If one route is unavailable, record that boundary and continue independent work within the requested contract. 5. Implement vertical slices: registry/contract → transport/normalization → event/bootstrap → formal discover/eval → config/status/init → surfaces. Reuse shared backend contracts and choose precedents per capability. Validate behavior at each affected boundary. 6. For source wiring, run the audit with the repository Python 3.11+ interpreter: `PYTHONPATH="$PWD/src" "$SOURCE_SKILL_PYTHON" scripts/audit_platform_source.py --contract --check --json`. Audit PASS proves registration evidence only. Review omissions against the raw contract, diff and artifacts; use an independent reviewer when requested or when the integration's risk warrants an authorized review, not as a mandatory extra process for every repair. 7. Record commands, exits and evidence levels in an acceptance copy. Only all-required `PASS` earns `complete` for the declared scope. Report `incremental only` for usable work with missing required proof, or `blocked` for work that cannot proceed. An audit/repair being complete does not certify the entire source. Report implemented, tested, merged, installed and released states separately. ## Preserve these boundaries - **Auth is per capability when needed.** Reuse `SourceCapabilityAuth` and `SourceAuthContract.capabilities` for `capability-specific` sources; check source-specific status/setup/init projections before declaring a prerequisite missing. Backend code owns account resolution. Observed identity is not verified identity; current authoritative failure overrides stale hints. Preserve omitted/clear/masked credential semantics, fingerprint-scoped evidence and 2xx warnings even when disabled. - **Content and transport evidence stay honest.** Namespaced stable IDs, canonical URLs, typed `author_name`, authoritative publication times and declared engagement availability must survive storage, DTOs and actual renderers. Follow only validated pagination destinations, including observed authenticated variants. Preserve accepted partial rows; no response, challenge HTML, parse failure and rate limit are not affirmative empty. - **Browser execution is a lifecycle.** Capability/online checks and local mutex precede atomic backend claim. Retain staged first-final-wins results, bounded durable replay and backend scope caps. Prove task isolation through SPA/full navigation and verify installed assets for the browsers claimed by the contract. - **Periodic sync is opt-in.** `source_incremental_enabled` defaults to false, including old configs without the key. Supporting incremental refresh must not enable it. Keep manual init, formal discovery, periodic bootstrap and native save distinct; test disabled scheduling and queued-task claim cancellation. Foreground task support is not permission to steal focus unattended. - **Discovery must produce usable supply.** Search sources need both keyword-generation tracks, `KeywordFetchCoordinator.claim()`, keyword identity/rollback, shared admission and shared cooldown across formal/inspiration paths. Show fetched → retained → evaluated → admitted counts; scheduler activity alone is insufficient. - **E2E proves one chain at a time.** Separate public transport, current-account → event → init/profile, discover → real configured LLM/embedding → recommendation, and installed UI evidence. Static markup/build success is not rendered UI or account E2E. Use isolated storage, check all declared smoke sinks and ordinary event deltas, and preserve the user's configured provider/model/route. - **Side effects follow the current request.** Carry forward authorization already given in this task; do not ask again at each gate or import permission from historical sessions. Upstream writes, production service changes and publication follow their actual scope. An uncertain native-save result permits read-only persisted-state verification, not another toggle. Complete independent authorized work before reporting a remaining external prerequisite.