# Post Translation Resource Handler

Audience: AI coding agents first.

- **ID:** IPZ-POST-TRANSLATION-RESOURCE-HANDLER-2026-08-15
- **Status:** IDLE
- **Task:** POST-HANDLER-01
- **Source request:** Continue every unfinished multilingual slice through session end. Site Content resource handling is published and dormant; recover the next smallest dependency-correct dispatch prerequisite without activating incomplete Site Content behavior.
- **Execution owner:** Current main coordinator only; no implementation delegation.

## Outcome

Publish a dormant `PostTranslationResourceHandler` implementing the current `TranslationResourceHandler` contract for existing post resources. Preserve current post translation request and finalization behavior exactly while isolating it behind the handler boundary needed for later two-resource dispatch. Add no construction, registration, dispatch switch, route, hook, schedule, UI, or visible behavior.

## Acceptance

- Implement exact current `TranslationResourceHandler` signatures for `supports()`, `prepare()`, and `finalize()`.
- Support only the current post resource types actually accepted by the existing translation pipeline. Reject `site_content`, string, bulk-string, malformed, or unknown resource types fail-closed; never use a catch-all that silently claims future types.
- Treat `content_id` as a WordPress post ID. Resolve and validate current post identity, type, language, target language, visibility, and bounded source fields through current published services and WordPress APIs.
- Preserve the current backend request contract for post title, excerpt, content, metadata, character accounting, source revision/correlation, and legacy receiver compatibility. Do not revive obsolete wrapper-HTML payloads or stale job shapes.
- Preserve current finalization behavior, including provider failure, job correlation, stale/duplicate callback handling, translation creation/update, hierarchy/layout fidelity already present, ACF policy, post metadata, publication state, and bounded safe errors.
- Reuse current `TranslationBridge`, `TranslationFinalizer`, `TranslationService`, `JobSender`, `JobReceiver`, DTO, and repository seams. Move no unrelated behavior and create no second finalization pipeline.
- Validate trust-boundary object/list/scalar shapes and IDs before mutation. Expose no source content, provider payload, credentials, database detail, or exception text in errors.
- Preserve PHP 8.0 and WordPress 6.0 compatibility; introduce no newer syntax beyond unavoidable pre-existing DTO constraints.
- Focused tests prove exact support, preparation, successful and failed finalization, malformed/stale/duplicate callbacks, legacy compatibility, safe errors, and no mutation before validation. Every claimed preserved behavior must have a regression test against current contracts.
- Add no runtime construction, handler registry, dispatcher wiring, route, hook, schedule, migration, feature activation, UI, backend request, or WordPress request.
- Run every applicable dependency install, test, lint, static analysis, security check, diagnostic, and related gate only through canonical remote execution on registry-selected `debian1`/`debian2`/`debian3`. Never run a local gate or fallback.

## Preserved WIP / ref / path

- Active worktree: `/home/user/Projects/Press.zone/wordpress/wp-content/.worktrees/site-content-post-handler`
- Branch: `wt/site-content-post-handler`
- Exact base: `aa56fce307a2c02aa34f36c37b5ef006755ea34f`
- Preserved carrier commits: `e9a2c64f6` and `09d3de3ac`.
- Preserved file is 1,045 lines and predates substantial current pipeline work. Treat it as behavioral evidence only. Do not transplant it wholesale.

## Allowed paths

- `includes/Translation/PostTranslationResourceHandler.php`
- Handler-only fixtures under `tests/Fixtures/Translation/`
- `tests/Unit/Translation/PostTranslationResourceHandlerTest.php`
- `phpunit.xml.dist` only if normal-suite registration is warning-free and introduces no fixture collision
- This plan, `docs/plans/INDEX.md`, `2026-08-14-site-content-translation-resource-handler.md`, and `2026-08-09-multilingual-site-entry-and-layout.md`
- Existing translation production or test files only for a reproduced missing prerequisite on exact current master. Record the acceptance delta before editing; do not fold dispatch wiring into this slice.

## Constraints

- Current source is authoritative. Compare preserved behavior method-by-method against exact current implementations before recovering code.
- Surgical recovery only. Prefer a thin adapter over copying 1,045 stale lines.
- No nested delegation, subagents, external models, or local gates.
- Do not overlap concurrent controller, catalog-fixture normalization, schema/provisioning, Page-layout, or admin UI lanes.
- Keep both handlers dormant until a later complete dispatch/activation slice can be verified end-to-end.

## Execution

1. Map exact current post request and finalization paths and their tests.
2. Compare preserved handler behavior against current contracts; classify every preserved branch as current, obsolete, or owned elsewhere.
3. Write focused regression tests that fail without the dormant handler.
4. Implement the smallest handler that delegates to current authoritative seams without duplicating business logic.
5. Run focused and applicable broad gates remotely only; address every signal.
6. Review trust boundaries, stale/duplicate correlation, mutations, compatibility, and dormancy directly; rerun affected remote gates.
7. Normal-commit through installed remote enforcement, land through the serialized isolated publisher, fetch exact `origin/master`, and prove dormancy remotely.
8. Publish final receipt and continue the next uncovered dispatch/controller slice.

## Current receipt

Site Content handler implementation `097a5f64b` is published in merge `aa56fce30`, with remote final testing and dormancy proof. Exact current master has `TranslationResourceHandler`, DTOs, post translation services, and `SiteContentTranslationResourceHandler`, but no `PostTranslationResourceHandler`, `SiteContentController`, or admin Site Content page.

Current-path mapping rejects a standalone post-handler port. The preserved 1,045-line candidate depends on `TranslationResult::$metadata['job']` and `['raw_data']`; current `TranslationResult` intentionally exposes only provider fields plus an attempt token. The exact current `TranslationFinalizer` requires authenticated local job identity and the full raw backend field map, while failure finalization and webhook delivery identity remain in `TranslateJobsController`. `TranslationJobDispatcher` also owns authoritative ACF extraction, source-revision locking, job creation, request construction, backend submission, and reconciliation. A standalone handler would therefore require either an unsafe latest-job lookup, hidden state, duplicated mutation logic, or concurrent public DTO/controller changes. None preserves current behavior as a dormant isolated slice.

Best-practice boundary: recover `PostTranslationResourceHandler` together with the later two-handler dispatch conversion, where job context, provider result, failure state, and webhook idempotency can move atomically under focused regression coverage. Do not add arbitrary metadata to `TranslationResult` or a partial handler merely to make this file exist.

## Next executable action

Keep IDLE until the coordinated two-resource dispatch slice. First publish and deploy the independent segmented backend prerequisite through `2026-08-15-segmented-site-content-backend.md`; then recover post adaptation, Site Content dispatch, and controller atomically.