Verify content rewriting pipeline is platform-agnostic (PR 8)

[prk-Jr]

Summary

• Verifies that the content rewriting pipeline (html_processor, streaming_processor, streaming_replacer, rsc_flight) has zero Fastly imports and requires no PlatformContentRewriter trait — future adapters (PR 16/17) need not implement any content-rewriting interface.
• Documents this outcome in platform/mod.rs, html_processor.rs, and streaming_processor.rs so it is discoverable for Cloudflare, Axum, and Spin adapter authors.
• The publisher.rs handler layer uses fastly::Body/Request/Response at its function boundaries, but this is an HTTP-type coupling addressed in Phase 2 (PR 11), not a content-rewriting concern.

Changes

File	Change
crates/trusted-server-core/src/platform/mod.rs	Add "Platform-Agnostic Components" section documenting no PlatformContentRewriter trait is needed
crates/trusted-server-core/src/html_processor.rs	Add # Platform notes section confirming zero Fastly imports
crates/trusted-server-core/src/streaming_processor.rs	Add # Platform notes section confirming StreamingPipeline::process is generic over R: Read + W: Write
crates/trusted-server-adapter-fastly/src/platform.rs	Fix unresolved intra-doc link (EdgeRequest → edgezero_core::http::Request) caught by cargo doc
crates/trusted-server-core/src/publisher.rs	Add platform-coupling note explaining fastly::Body/Request/Response usage is an HTTP-type concern, not content-rewriting
docs/superpowers/plans/2026-03-31-pr8-content-rewriting-verification.md	Add implementation plan for this PR

Closes

Closes #489

Test plan

• cargo test --workspace
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo fmt --all -- --check
• JS tests: cd crates/js/lib && npx vitest run
• JS format: cd crates/js/lib && npm run format
• Docs format: cd docs && npm run format
• WASM build: cargo build --package trusted-server-adapter-fastly --release --target wasm32-wasip1
• Manual testing via fastly compute serve

Checklist

• Changes follow CLAUDE.md conventions
• No unwrap() in production code — use expect("should ...")
• Uses log macros (not println!)
• New code has tests
• No secrets or credentials committed

[aram356]

Summary

Documentation-only PR (plus one intra-doc link fix) that verifies the content rewriting pipeline is platform-agnostic. Core claims are accurate — html_processor, streaming_processor, streaming_replacer, and rsc_flight have zero fastly imports. Good separation of concerns that saves future adapter authors from implementing unnecessary abstractions.

Non-blocking

🤔 thinking

• Broken intra-doc link syntax in html_processor.rs:12 — `impl `[`StreamProcessor`] has an awkward space between backtick-wrapped impl and the link. Consider `impl` [`StreamProcessor`] or plain `impl StreamProcessor`.
• Missing blank line before use in html_processor.rs:17-18 — The original file had a blank line between the doc block and imports. Lost in the edit; inconsistent with streaming_processor.rs which has the blank line.

♻️ refactor

• publisher.rs caveat in platform/mod.rs:31-37 — The handler-coupling detail feels like it belongs in publisher.rs itself rather than the platform module doc. Consider moving it there and keeping platform/mod.rs focused on what adapters need to know.

🌱 seedling

• PR number references in doc comments may age poorly — "PR 8", "PR 11", "PR 16/17" will be opaque without EdgeZero migration context. Consider more descriptive labels (e.g., "the HTTP-type migration" instead of "PR 11").

⛏ nitpick

• StreamingPipeline::process<R: Read, W: Write> in platform/mod.rs:27 — Angle brackets are plain text, not a link or code. Should be wrapped in backticks or use an intra-doc link.

👍 praise

• Good call not introducing a PlatformContentRewriter trait — the pipeline is already generic.
• Nice catch fixing the unresolved EdgeRequest doc link.

CI Status

• integration tests: PASS
• browser integration tests: PASS
• prepare integration artifacts: PASS

[aram356]

Summary

Documentation-only PR that verifies the content rewriting pipeline is platform-agnostic and documents this for future adapter authors. The doc comments are well-structured and the separation of concerns (platform-agnostic pipeline vs platform-coupled handler layer) is correctly captured.

Blocking

🔧 wrench

• Unresolved intra-doc link: StreamingPipeline::process in platform/mod.rs:26 does not resolve — StreamingPipeline is not in scope from the platform module. This is a new cargo doc warning not present on the base branch. Needs the full path.

• Inconsistent PR number references: streaming_processor.rs still uses opaque "PR 8" (line 11) and "PR 16/17" (line 17) while html_processor.rs and platform/mod.rs were updated to descriptive labels in commit 2333227. This file was missed.

Non-blocking

🤔 thinking

• 350-line plan document: docs/superpowers/plans/2026-03-31-pr8-content-rewriting-verification.md is an agentic implementation plan with task checkboxes and bash commands — 350 lines of process artifact for ~55 lines of doc comment changes. It also still contains opaque "PR 8"/"PR 11"/"PR 16/17" references. Is this pattern intended to be kept long-term, or should plans be cleaned up after the PR ships?

CI Status

• integration tests: PASS
• browser integration tests: PASS
• prepare integration artifacts: PASS

[aram356]

Summary

Verified the core claim: grep confirms zero fastly imports in html_processor.rs, streaming_processor.rs, streaming_replacer.rs, and rsc_flight.rs. cargo doc --no-deps --all-features produced no new warnings (15 pre-existing, all unrelated to this PR). CI is green across all three checks. The audit table in the plan doc is a useful artifact to leave behind for future adapter authors.

Non-blocking

🤔 thinking

• Self-referential module doc — crates/trusted-server-core/src/publisher.rs:1-7 speaks about "publisher.rs" from inside publisher.rs. Rust module docs should speak in first person ("this module"). Also worth noting: publisher.rs isn't in the plan's File Map — it appeared in the "Address PR review feedback" commit. Consider rewording to "Publisher response handler. Platform coupling: this module is currently coupled to fastly::Body/Request/Response at its handler boundaries..."

♻️ refactor

• Tautological verification label — Three sites (platform/mod.rs, html_processor.rs, streaming_processor.rs) say "(verified in the content rewriting verification)". An earlier draft said "PR 8" and got genericized into a circular phrase. Prefer a durable pointer like (Verified 2026-03-31; see docs/superpowers/plans/2026-03-31-pr8-content-rewriting-verification.md.) or drop the parenthetical entirely — the surrounding paragraph already conveys the reasoning.

⛏ nitpick

• Awkward impl code span — html_processor.rs:12 renders as two separate code spans: `impl` then a linked StreamProcessor. Prefer `impl `[`StreamProcessor`] (single styled run) or `impl StreamProcessor` (no link).
• Vague forward reference — "future adapters (subsequent adapter migrations)" appears in all three modified module docs. The original plan named Cloudflare / Axum / Spin explicitly; either name the targets or drop the parenthetical.
• PR body Changes table is incomplete — The table lists 5 files but the diff touches 6; publisher.rs is only alluded to in Summary bullet 3.
• Stale checklist template — PR checklist says "Uses tracing macros (not println!)" but this project standardizes on log (with log-fastly). Template drift only.

🌱 seedling

• Silent sibling modules — The plan intentionally skips streaming_replacer.rs and rsc_flight.rs as internal. Fine, but a one-line //! See [\crate::platform`] module doc for platform notes.` at the top of each would make them self-documenting for anyone grepping "platform" directly in the file.

🏕 camp site

• Pre-existing cargo doc warnings — 15 unresolved/private intra-doc links across lib.rs, auction/provider.rs, consent/types.rs, redacted.rs, tsjs.rs, and a few integration modules. Out of scope here, but since this is a documentation-quality PR, a follow-up sweep would noticeably lift cargo doc hygiene.

👍 praise

• Clean separation of concerns — crates/trusted-server-core/src/platform/mod.rs:15-30: the publisher-layer coupling was correctly reclassified as an HTTP-type concern rather than conflated with content-rewriting, and the publisher note was relocated from platform/mod.rs (plan draft) into publisher.rs itself (final version) in response to earlier review feedback. Good response to review, good taxonomy.

CI Status

• browser integration tests: PASS
• integration tests: PASS
• prepare integration artifacts: PASS