Problem
Two required-scope requirements from devvit-migration/docs/01-requirements.md were marked DONE in the original STATUS.md but are not implemented. Verified by executing the compiled pipeline against devvit/src/render.ts and devvit/src/modlog.ts.
- FR-7 — Combined removal+reason rows (
01-requirements.md:102): a removal and its subsequent addremovalreason for the same content should merge into one row. No such merge/correlation exists anywhere in the pipeline.
- FR-8 — Conditional approval rows (
01-requirements.md:105): an approval should render only when it reverses a prior Reddit/AutoMod removal, annotated "Approved <mod> removal[: reason]". No such gating exists.
render.ts:225-235 (renderRow) maps each ModAction → one ModRecord → one independent table row, with no lookback at prior records. The architecture spec assigns this correlation logic to render.ts explicitly (04-architecture.md:136, "approval-correlation render (P-13)") and the requirements doc flags the design risk in R-3 (01-requirements.md:187) — a per-content secondary index in Redis is needed since Redis has no ad-hoc LIKE query the legacy SQLite version used. None of that index or correlation code exists in storage.ts or modlog.ts either.
Fix
Implement the correlation layer per R-3's proposed design (a Redis hash/sorted-set secondary index keyed by content id, capturing the prior removal's moderator + reason, bounded by retention) and wire FR-7/FR-8 logic into render.ts (or a new module) before this scaffold is considered parity-complete.
References
PR #34 (feat/devvit-migration), devvit-migration/docs/STATUS.md §5.
Problem
Two required-scope requirements from
devvit-migration/docs/01-requirements.mdwere marked DONE in the originalSTATUS.mdbut are not implemented. Verified by executing the compiled pipeline againstdevvit/src/render.tsanddevvit/src/modlog.ts.01-requirements.md:102): a removal and its subsequentaddremovalreasonfor the same content should merge into one row. No such merge/correlation exists anywhere in the pipeline.01-requirements.md:105): an approval should render only when it reverses a prior Reddit/AutoMod removal, annotated"Approved <mod> removal[: reason]". No such gating exists.render.ts:225-235(renderRow) maps eachModAction→ oneModRecord→ one independent table row, with no lookback at prior records. The architecture spec assigns this correlation logic torender.tsexplicitly (04-architecture.md:136, "approval-correlation render (P-13)") and the requirements doc flags the design risk in R-3 (01-requirements.md:187) — a per-content secondary index in Redis is needed since Redis has no ad-hocLIKEquery the legacy SQLite version used. None of that index or correlation code exists instorage.tsormodlog.tseither.Fix
Implement the correlation layer per R-3's proposed design (a Redis hash/sorted-set secondary index keyed by content id, capturing the prior removal's moderator + reason, bounded by retention) and wire FR-7/FR-8 logic into
render.ts(or a new module) before this scaffold is considered parity-complete.References
PR #34 (
feat/devvit-migration),devvit-migration/docs/STATUS.md§5.