zenmemes Platform Docs

Docs home

Documents

1,591 documents

Filters
  1. Activity Commit File Manifest — Step 2: Feature Description

    An activity event represents one record, but its commit can change several files.

    docs/plans/archive/activity_commit_file_manifest_step2_feature_description.md Plans

  2. Activity Commit File Manifest — Step 3: Development Plan

    Reply Approved Step 3 to begin implementation on a feature branch.

    docs/plans/archive/activity_commit_file_manifest_step3_development_plan.md Plans

  3. Activity Commit File Manifest — Step 4: Implementation Summary

    docs/plans/archive/activity_commit_file_manifest_step4_implementation_summary.md Plans

  4. Activity Manifest Readability — Step 2: Feature Description

    Activity cards repeat source/signature filenames above the commit manifest, and inline manifest paths are hard to scan.

    docs/plans/archive/activity_manifest_readability_step2_feature_description.md Plans

  5. Activity Manifest Readability — Step 3: Development Plan

    Reply Approved Step 3 to begin implementation on a feature branch.

    docs/plans/archive/activity_manifest_readability_step3_development_plan.md Plans

  6. Activity Manifest Readability — Step 4: Implementation Summary

    docs/plans/archive/activity_manifest_readability_step4_implementation_summary.md Plans

  7. Activity Source Links Slices Plan

    Make the activity page source metadata actionable:

    docs/plans/archive/activity_source_links_slices_v1.md Plans

  8. Agent Reply Request Button Step 1 Solution Assessment

    Users need an intentional in-page control that requests a reply-agent response for a specific post without relying on automatic browser-triggered reply work.

    docs/plans/archive/agent_reply_request_button_step1_solution_assessment.md Plans

  9. 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

  10. Agent Reply Request Button Step 3 Development Plan

    docs/plans/archive/agent_reply_request_button_step3_development_plan.md Plans

  11. Agent Reply Request Button Step 4 Implementation Summary

    docs/plans/archive/agent_reply_request_button_step4_implementation_summary.md Plans

  12. 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

  13. 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

  14. All Activity Feed

    docs/plans/archive/all_activity_feed_step3_development_plan.md Plans

  15. All Activity Feed Implementation Summary

    docs/plans/archive/all_activity_feed_step4_implementation_summary.md Plans

  16. 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

  17. 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

  18. Approved Members Identity Publication Step 3 Development Plan

    docs/plans/archive/approved_members_identity_publication_step3_development_plan.md Plans

  19. Approved Members Identity Publication Step 4 Implementation Summary

    docs/plans/archive/approved_members_identity_publication_step4_implementation_summary.md Plans

  20. 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

  21. 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

  22. Backup Page Freshness Preview Step 3 Development Plan

    docs/plans/archive/backup_page_freshness_preview_step3_development_plan.md Plans

  23. Backup Page Freshness Preview Step 4 Implementation Summary

    docs/plans/archive/backup_page_freshness_preview_step4_implementation_summary.md Plans

  24. 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

  25. 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

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

    docs/plans/archive/board_activity_carryback_step3_development_plan.md Plans

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

    docs/plans/archive/board_activity_carryback_step4_implementation_summary.md Plans

  28. 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

  29. 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

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

    docs/plans/archive/board_list_column_reflow_step3_development_plan.md Plans

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

    docs/plans/archive/board_list_column_reflow_step4_implementation_summary.md Plans

  32. 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

  33. 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

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

    docs/plans/archive/chouse_approved_members_only_access_step3_development_plan.md Plans

  35. 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

  36. 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

  37. 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

  38. 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

  39. Codebase State Feature Plan

    Implementation completed on feature/codebase-state.

    docs/plans/archive/codebase_state_feature_plan_v1.md Plans

  40. 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