zenmemes Platform Docs

Docs home

Documents

1,681 documents

Filters
  1. Agent Reply Request Button Step 2 Feature Description

    Agent replies currently depend on automatic post-load work or direct API calls, so a user cannot intentionally ask for an agent response from the page they are…

    docs/plans/archive/agent_reply_request_button_step2_feature_description.md Plans Plans and history

  2. Agent Reply Request Button Step 3 Development Plan

    docs/plans/archive/agent_reply_request_button_step3_development_plan.md Plans Plans and history

  3. Agent Reply Request Button Step 4 Implementation Summary

    docs/plans/archive/agent_reply_request_button_step4_implementation_summary.md Plans Plans and history

  4. All Activity Feed

    Users need immediate confidence that every frontend action they take has been durably represented in the content repository and is visible in All Activity, inc…

    docs/plans/archive/all_activity_feed_step1_solution_assessment.md Plans Plans and history

  5. All Activity Feed

    Users need confidence during demos and daily use that successful frontend actions were durably written to the content repository.

    docs/plans/archive/all_activity_feed_step2_feature_description.md Plans Plans and history

  6. All Activity Feed

    docs/plans/archive/all_activity_feed_step3_development_plan.md Plans Plans and history

  7. All Activity Feed Implementation Summary

    docs/plans/archive/all_activity_feed_step4_implementation_summary.md Plans Plans and history

  8. Approved Members Identity Publication Step 1 Solution Assessment

    In a private approved-members-only instance, an unapproved user must automatically publish a new browser key’s public key, create or reuse the corresponding pr…

    docs/plans/archive/approved_members_identity_publication_step1_solution_assessment.md Plans Plans and history

  9. Approved Members Identity Publication Step 2 Feature Description

    Private approved-members-only instances currently allow a browser key to reach a prepared identity state without reliably completing profile publication.

    docs/plans/archive/approved_members_identity_publication_step2_feature_description.md Plans Plans and history

  10. Approved Members Identity Publication Step 3 Development Plan

    docs/plans/archive/approved_members_identity_publication_step3_development_plan.md Plans Plans and history

  11. Approved Members Identity Publication Step 4 Implementation Summary

    docs/plans/archive/approved_members_identity_publication_step4_implementation_summary.md Plans Plans and history

  12. Backup Page Freshness Preview Step 1 Solution Assessment

    Users need the backup page to show backup freshness and recent included items before download.

    docs/plans/archive/backup_page_freshness_preview_step1_solution_assessment.md Plans Plans and history

  13. Backup Page Freshness Preview Step 2 Feature Description

    The public Backup page offers downloadable snapshots but does not tell users when the available artifacts were generated or what recent content they contain.

    docs/plans/archive/backup_page_freshness_preview_step2_feature_description.md Plans Plans and history

  14. Backup Page Freshness Preview Step 3 Development Plan

    docs/plans/archive/backup_page_freshness_preview_step3_development_plan.md Plans Plans and history

  15. Backup Page Freshness Preview Step 4 Implementation Summary

    docs/plans/archive/backup_page_freshness_preview_step4_implementation_summary.md Plans Plans and history

  16. Step 1: Solution Assessment — Board/Activity Carry-Back (+ Board Score column)

    Port two confirmed-applicable, low-risk improvements from the Forte Users rebuild — relative-date list rows and a Score column — to Board and Activity.

    docs/plans/archive/board_activity_carryback_step1_solution_assessment.md Plans Plans and history

  17. Step 2: Feature Description — Board/Activity Carry-Back (+ Board Score column)

    Board and Activity list rows show full-precision timestamps instead of the scannable relative format Users already has, and Board has no way to see or sort by…

    docs/plans/archive/board_activity_carryback_step2_feature_description.md Plans Plans and history

  18. Step 3: Development Plan — Board/Activity Carry-Back (+ Board Score column)

    docs/plans/archive/board_activity_carryback_step3_development_plan.md Plans Plans and history

  19. Step 4: Implementation Summary — Board/Activity Carry-Back (+ Board Score column)

    docs/plans/archive/board_activity_carryback_step4_implementation_summary.md Plans Plans and history

  20. Step 1: Solution Assessment — Board List Column Reflow

    At half-wide window widths, Board's fixed-width From (9rem) and Date (13rem) columns are often wider than their content needs — especially Date, now that relat…

    docs/plans/archive/board_list_column_reflow_step1_solution_assessment.md Plans Plans and history

  21. Step 2: Feature Description — Board List Column Reflow

    Board's From and Date list columns are fixed-width and often wider than their content needs at half-wide window widths, wasting space while the flexible Subjec…

    docs/plans/archive/board_list_column_reflow_step2_feature_description.md Plans Plans and history

  22. Step 3: Development Plan — Board List Column Reflow

    docs/plans/archive/board_list_column_reflow_step3_development_plan.md Plans Plans and history

  23. Step 4: Implementation Summary — Board List Column Reflow

    docs/plans/archive/board_list_column_reflow_step4_implementation_summary.md Plans Plans and history

  24. Chouse Approved-Members-Only Access — Step 1: Solution Assessment

    Chouse should be a private approved-members site: unapproved visitors may

    docs/plans/archive/chouse_approved_members_only_access_step1_solution_assessment.md Plans Plans and history

  25. Chouse Approved-Members-Only Access — Step 2: Feature Description

    Chouse is intended to be a private approved-members site.

    docs/plans/archive/chouse_approved_members_only_access_step2_feature_description.md Plans Plans and history

  26. Chouse Approved-Members-Only Access — Step 3: Development Plan

    docs/plans/archive/chouse_approved_members_only_access_step3_development_plan.md Plans Plans and history

  27. Chouse Approved-Members-Only Access — Step 4: Implementation Summary

    signature verification endpoint.

    docs/plans/archive/chouse_approved_members_only_access_step4_implementation_summary.md Plans Plans and history

  28. Chouse Theme — Step 2: Feature Description

    chouse.club has no dedicated visual identity in this codebase yet — a

    docs/plans/archive/chouse_theme_step2_feature_description.md Plans Plans and history

  29. Chouse Theme — Step 3: Development Plan

    Note: chouse.club's live header includes a "Continue to Markit event page"

    docs/plans/archive/chouse_theme_step3_development_plan.md Plans Plans and history

  30. Chouse Theme — Step 4: Implementation Summary

    Note: this summary was written retroactively alongside Stage 5, after

    docs/plans/archive/chouse_theme_step4_implementation_summary.md Plans Plans and history

  31. Codebase State Feature Plan

    Implementation completed on feature/codebase-state.

    docs/plans/archive/codebase_state_feature_plan_v1.md Plans Plans and history

  32. Compact Mode Cleanup Step 1 Solution Assessment

    Compact mode needs to retain its existing button and composer appearance while removing unnecessary surrounding space and side rails between the board cards.

    docs/plans/archive/compact_mode_menu_buttons_step1_solution_assessment.md Plans Plans and history

  33. Compact Mode Cleanup Step 2 Feature Description

    Compact mode still presents unnecessary surrounding space and vertical side rails around the board controls, thread composer, and thread cards.

    docs/plans/archive/compact_mode_menu_buttons_step2_feature_description.md Plans Plans and history

  34. Compact Mode Cleanup Step 3 Development Plan

    docs/plans/archive/compact_mode_menu_buttons_step3_development_plan.md Plans Plans and history

  35. Compact Mode Cleanup Step 4 Implementation Summary

    docs/plans/archive/compact_mode_menu_buttons_step4_implementation_summary.md Plans Plans and history

  36. Cron Task Queue — Step 1: Solution Assessment

    The application needs a durable way to enqueue internal maintenance work, such as read-model recovery, for a bounded cron worker to execute outside a visitor r…

    docs/plans/archive/cron_task_queue_step1_solution_assessment.md Plans Plans and history

  37. Cron Task Queue — Step 2: Feature Description

    Maintenance work that cannot safely run in a visitor request needs a durable handoff to cron.

    docs/plans/archive/cron_task_queue_step2_feature_description.md Plans Plans and history

  38. Cron Task Queue — Step 3: Development Plan

    docs/plans/archive/cron_task_queue_step3_development_plan.md Plans Plans and history

  39. Cron Task Queue — Step 4: Implementation Summary

    docs/plans/archive/cron_task_queue_step4_implementation_summary.md Plans Plans and history

  40. Cross Thread Reference Search Step 1 Solution Assessment

    When a user post references another discussion or asks a question already answered elsewhere, the application should find relevant existing threads/comments an…

    docs/plans/archive/cross_thread_reference_search_step1_solution_assessment.md Plans Plans and history