typo3-upgrade-intake

# TYPO3 upgrade intake One job: prove exactly what will be upgraded and define the graph before mutation. ## Preconditions - `typo3-upgrade-run` initialized the local run and selected one project. - Work is inside a local DDEV clone. No staging/live access or sync action is authorized. - Read `../typo3-upgrade-run/references/recent-run-lessons.md`. ## Evidence checklist 1. Record repository root, canonical remote, branch, HEAD, dirty/untracked ownership, DDEV root/name, primary URL, database identity, and installed TYPO3 core. Refuse any mismatch. 2. Record database dump/source date, maximum `pages` and `tt_content` timestamps, table/row sentinels, fileadmin count/hash, and one known page/content/media sentinel. A reachable empty or wrong database is a finding, not a usable baseline. 3. Inspect sites/languages/bases, sitemaps, robots/canonical behavior, page-tree fallback, golden paths, dynamic routes, backend entry point, and local mail/search services. Name uncovered routes. 4. Inventory every installed/local/abandoned extension and feature usage. Preserve exact output of: ```bash ddev composer why-not typo3/cms-core "^14.3" ddev composer why-not php 8.5 ddev composer audit --locked --format=json ``` 5. Require one resolution strategy per v14 blocker; do not implement it here. Apply [native tools first](../typo3-upgrade-run/references/native-tools-first.md): inventory existing Core commands/wizards before proposing scripts or dependencies; new optional extensions need dated adoption, maintenance and compatibility evidence. Put the choice in existing node evidence. 6. Check `typo3/cms-redirects` and `spooner/deployer-information`. If absent, activate dependency resolution. Always activate the editor-rights verification branch for Redirects. 7. Identify Mask/Content Blocks, Vite/assets, Solr/search, RTE/Visual Editor, Powermail/forms, scheduler, custom backend modules/rights, local extensions, and schema/data migrations. Read [fleet regression contracts](../typo3-upgrade-run/references/fleet-regression-contracts.md). Inventory actual mail/DOI/CAPTCHA entry points, tracking context/consent, cache dependencies, historical routes and persisted business records. Record applicability once, with representative journeys and named assertions in the [feature plan](../typo3-upgrade-run/references/feature-evidence.md). 8. Record credential origins without reading/printing values. Reject committed/hard-coded secrets, ambiguous origins, production sessions, or cross-origin credential flows as security findings. Inventory the env loader, Bootstrap version, jQuery/plugin dependencies and the live-sync helper without executing it. Plan their scoped modernization; read the orchestrator's [project environment](../typo3-upgrade-run/references/project-environment.md) for the dotenv/config-handling distinction. 9. Verify backup capability: artifact type, timestamp, checksum, target identity, restore command, and storage path. This is readiness evidence; take snapshots only immediately before stateful nodes. 10. Read `../typo3-upgrade-run/references/runtime-sizing.md`. Record all nine sizing metrics and their source artifacts in `nodes/intake/runtime-size.json`; select no profile yourself. Let `t3u runtime-seal` calculate and seal the smallest fitting small/large/huge profile. 11. Produce risk/cost order, graph applicability outcomes, and a smallest-decision list for the user. 12. Resolve known approvals before unattended execution. Forecast work from measured capture/test throughput as well as site size. Read `../typo3-upgrade-run/references/overnight-controller.md`, write the selected-route runtime plan and run `t3u graph-forecast` before the baseline. A missing or non-fitting estimate blocks admission. The size-dependent 8/24/48h caps are not completion guarantees. ## Routes - `pass`: identity, dated dataset decision, sites/URLs, blockers, credentials boundary, and graph applicability are evidenced. - `findings`: route identity, dataset, sitemap/discovery, dependency, or credential issue to its specific recovery node. - `blocked`: wrong/ambiguous project, secret exposure, no acceptable data, unsafe origin, or an unavailable decision prevents a safe run. ## Output Write node evidence under `.typo3-update/nodes/` and manifests under `.typo3-update/manifests/`. Include commands and exit codes, hashes, unresolved facts, approvals/ADRs needed, selected routes, explicit non-applicable branches, and the runtime-sizing evidence. Do not say “ready” when any identity, dataset, or sizing field is inferred. For a new default graph, close `intake-join` with `manifests/feature-contracts.json` as its evidence. This hash-sealed plan reuses inventory artifacts; it does not introduce extra browser passes. ## Boundaries Use `typo3-upgrade-baseline` for deterministic capture, `typo3-upgrade-migration` for changes, and `typo3-upgrade-retrospective` when reconstructing an old run. Use `typo3-ddev` for DDEV mechanics, but keep this skill responsible for the upgrade-specific identity verdict.