Post-import feedback automation — implementation checklist

Outline of the manual workflow used on October 21, 2026, for a future automation. This document records implementation work to do; it does not implement or approve the automation. Importing content is a prerequisite and is outside this checklist.

Reference output: October 21 feedback summary. Format reference: existing meta feedback summary.

1. Capture the request and source snapshot

• Accept the source instance, local content repository, requested time window, and timezone. Support relative windows such as “the past hour or two,” resolved once against a recorded reference time.

• Accept an optional author identity and output date; do not assume that every poster is the requesting user.

• Read the latest import report and record its run ID, content commit, and partial-import limitations. Operate on accepted local records without downloading or importing again.

• Record the exact UTC window, local-time equivalent, and snapshot cutoff in the generated summary. Distinguish the request time from the latest available source data.

2. Discover recent feedback

• Read canonical post headers and bodies, selecting by Created-At rather than file modification time, path order, or import commit date.

• Search all posts in the requested window, including roots and replies, without requiring meta, todo, or any other tag.

• Resolve thread and parent relationships to recover context for terse replies such as “also” or “this one.” Label older context separately from in-window requests.

• Identify the likely feedback author from the request and source context. Flag ambiguous attribution rather than silently presenting another author's suggestions as the user's requests.

• Separate actionable requests about this repository from social posts, automated replies, bootstrap records, thread markers, and feedback about external products.

• Retain a source inventory and exclusion reasons so the coverage can be reviewed.

3. Compile trackable items

• Extract each distinct requested change or reported problem. Split combined posts when they describe independently trackable work.

• Merge repeated requests while retaining every supporting source link; avoid merging superficially similar reports with different symptoms or scope.

• Preserve qualifiers and uncertainty: “brainstorm,” “maybe,” and questions remain exploratory rather than becoming committed requirements.

• Preserve concrete details such as exact UI text, commands, routes, failure messages, focus behavior, and suggested visual treatment.

• Classify items as feature requests, bug reports, or Other. Keep external-product feedback and housekeeping out of the actionable repository inventory.

• Do not invent implementation decisions or claim a root cause from a symptom report.

4. Render the established summary format

• Produce an introduction describing the source, dates, included thread/post counts, tag-independent selection, and partial-import or snapshot limitations.

• Render separate Feature requests and Bug reports tables with Item, Request/Report, Sources, Railspike cycles, and Status columns.

• Number items consistently within each section, matching the reference summary.

• Use source post IDs as link labels and instance /posts/{id} permalinks as targets.

• Include provisional Railspike cycle estimates on the reference's nonnegative decimal scale, clearly labeled as estimates rather than approved plans or commitments. Mark unavailable estimates explicitly instead of fabricating them.

• Default to “Open — resolution not verified.” Change a status only when explicit evidence supports it; retain local, production, visual, and physical-device verification limits.

• Add Other and related historical-feedback notes where useful. Cross-reference an earlier item without treating an adjacent fix as proof of resolution.

• Include a Source inventory table with thread link, date, post count, and topic. State whether counts include the opening post and older context.

• Escape Markdown table delimiters and normalize multiline content without losing meaning.

5. Name and save the artifact

• Write directly to docs/plans/zenmemes_meta_feedback_YYYY-MM-DD_summary.md, using the agreed report date. Avoid an intermediate “recent todos” filename and subsequent rename.

• Preserve an existing report when the target filename already exists; support an explicit reviewed update or a distinct output filename.

• Keep generated summaries outside the vendored Railspike tree and leave todo.txt untouched.

• Write the completed output atomically so interruption cannot leave a truncated report.

• Retain enough provenance to recognize a repeated run against the same snapshot and inputs. If updating an existing report, preserve reviewed statuses, evidence, and manual notes.

6. Verify and hand off

• Verify that every extracted actionable request appears once, all source links resolve to included local records, and every item can be traced to its source text.

• Check counts, timestamps, section numbering, table structure, and repository-relative document links.

• Exercise representative cases: untagged feedback, replies to older threads, ambiguous authors, duplicate requests, combined requests, exploratory ideas, external-product feedback, partial imports, empty windows, date boundaries, and existing output files.

• Use the October 21 snapshot as an acceptance fixture: recover the 13 actionable replies in the todo thread and the same 16 distinct requests; the source inventory includes 14 posts with the root marker.

• Compare meaning and source coverage with the reference summary rather than requiring identical prose or invented precision in estimates.

• Run git diff --check and review the generated Markdown. Verify rendered tables in the intended viewer, especially long source links and request text.

• Return a clickable local file link and a concise account of included items, omissions, and unresolved attribution or coverage questions.

Optional terminal viewing

The conversation also covered reading the output in Ubuntu with Glow. This is a convenience after generation, not a required dependency of the automation.

• Document an optional preview command: glow -p docs/plans/zenmemes_meta_feedback_YYYY-MM-DD_summary.md.

• Keep viewer installation separate from report generation; do not install packages or change system repositories as a side effect.

Planning boundary

Before implementing this automation, use the repository's Railspike workflow to select the entry point and agree on extraction, rerun, and review behavior. This retrospective checklist does not select a CLI command name, add scheduling, publish to the source instance, or authorize implementing the feedback items themselves.