-
Invite Destination Selector — Step 2: Feature Description
The invites page always shows a disabled destination input and makes members type every destination, even when they are repeatedly inviting people to common or…
docs/plans/archive/invite_destination_selector_step2_feature_description.md Plans Plans and history
-
Invite Destination Selector — Step 3: Development Plan
docs/plans/archive/invite_destination_selector_step3_development_plan.md Plans Plans and history
-
Invite Destination Selector — Step 4: Implementation Summary
docs/plans/archive/invite_destination_selector_step4_implementation_summary.md Plans Plans and history
-
Invite Session Authentication: Step 1 Solution Assessment
On a public instance, the Account page can show an approved browser identity and the Invite link, while the invitation route cannot read that authenticated ses…
docs/plans/archive/invite_session_authentication_step1_solution_assessment.md Plans Plans and history
-
Invite Session Authentication: Step 2 Feature Description
On a public instance, an approved member with a saved browser key is not consistently recognized after their server session expires.
docs/plans/archive/invite_session_authentication_step2_feature_description.md Plans Plans and history
-
Invite Session Authentication: Step 3 Development Plan
docs/plans/archive/invite_session_authentication_step3_development_plan.md Plans Plans and history
-
Invite Session Authentication: Step 4 Implementation Summary
docs/plans/archive/invite_session_authentication_step4_implementation_summary.md Plans Plans and history
-
iOS Users Page Cache Freshness Step 1 Solution Assessment
iOS users need the users page to show fresh state instead of stale cached content.
docs/plans/archive/ios_users_page_cache_freshness_step1_solution_assessment.md Plans Plans and history
-
iOS Users Page Cache Freshness Step 2 Feature Description
Users can see stale cached content on the approved users page after user/profile state changes, with iOS reported as the affected client.
docs/plans/archive/ios_users_page_cache_freshness_step2_feature_description.md Plans Plans and history
-
iOS Users Page Cache Freshness Step 3 Development Plan
docs/plans/archive/ios_users_page_cache_freshness_step3_development_plan.md Plans Plans and history
-
iOS Users Page Cache Freshness Step 4 Implementation Summary
docs/plans/archive/ios_users_page_cache_freshness_step4_implementation_summary.md Plans Plans and history
-
links_browser_accessibility_step1_solution_assessment.md
Status: Archived at user request on 2026-10-13; deferred, not approved or implemented.
docs/plans/archive/links_browser_accessibility_step1_solution_assessment.md Plans Plans and history
-
LLM Prompt and Response Visibility Step 1 Solution Assessment
Operators and approved users need to inspect the exact prompt sent to the LLM and the exact response received when an LLM call occurs, but the current implemen…
docs/plans/archive/llm_prompt_response_visibility_step1_solution_assessment.md Plans Plans and history
-
LLM Prompt and Response Visibility Step 2 Feature Description
LLM activity is currently only partially observable: approved users can see selected post-analysis results, and operators can inspect limited diagnostics, but…
docs/plans/archive/llm_prompt_response_visibility_step2_feature_description.md Plans Plans and history
-
LLM Prompt and Response Visibility Step 3 Development Plan
docs/plans/archive/llm_prompt_response_visibility_step3_development_plan.md Plans Plans and history
-
LLM Prompt and Response Visibility Step 4 Implementation Summary
docs/plans/archive/llm_prompt_response_visibility_step4_implementation_summary.md Plans Plans and history
-
Redeemable Board Invitations — Step 1: Solution Assessment
An approved user should be able to invite a recipient who creates a new,
docs/plans/archive/lobby_board_invite_link_step1_solution_assessment.md Plans Plans and history
-
Redeemable Board Invitations — Step 2: Feature Description
Private boards require a recipient to have an identity before an approved user
docs/plans/archive/lobby_board_invite_link_step2_feature_description.md Plans Plans and history
-
Redeemable Board Invitations — Step 3: Development Plan
docs/plans/archive/lobby_board_invite_link_step3_development_plan.md Plans Plans and history
-
Redeemable Board Invitations — Step 4: Implementation Summary
docs/plans/archive/lobby_board_invite_link_step4_implementation_summary.md Plans Plans and history
-
Localhost Codex Task Handoff Step 1 Solution Assessment
Approved users on localhost need a deliberate UI workflow that converts a forum request into a Codex-ready feature handoff, shows the proposed handoff for one…
docs/plans/archive/localhost_codex_task_handoff_step1_solution_assessment.md Plans Plans and history
-
Localhost Codex Task Handoff Step 2 Feature Description
Approved users reading the local site need a safe way to turn a forum request into a Codex-ready development handoff.
docs/plans/archive/localhost_codex_task_handoff_step2_feature_description.md Plans Plans and history
-
Localhost Codex Task Handoff Step 3 Development Plan
docs/plans/archive/localhost_codex_task_handoff_step3_development_plan.md Plans Plans and history
-
Localhost Codex Task Handoff Step 4 Implementation Summary
docs/plans/archive/localhost_codex_task_handoff_step4_implementation_summary.md Plans Plans and history
-
Multi Provider LLM Config Step 1 Solution Assessment
Instance operators need to choose a reliable LLM provider for post analysis and reply generation instead of being locked to Dedalus.
docs/plans/archive/multi_provider_llm_config_step1_solution_assessment.md Plans Plans and history
-
Multi Provider LLM Config Step 2 Feature Description
The application currently exposes LLM setup through Dedalus-specific config, which makes production recovery difficult when Dedalus is unavailable and obscures…
docs/plans/archive/multi_provider_llm_config_step2_feature_description.md Plans Plans and history
-
Multi Provider LLM Config Step 3 Development Plan
docs/plans/archive/multi_provider_llm_config_step3_development_plan.md Plans Plans and history
-
Multi Provider LLM Config Step 4 Implementation Summary
docs/plans/archive/multi_provider_llm_config_step4_implementation_summary.md Plans Plans and history
-
Multi-Site Config — Step 1: Solution Assessment
One codebase must serve zenmemes.com and chouse.club as separately
docs/plans/archive/multi_site_config_step1_solution_assessment.md Plans Plans and history
-
Multi-Site Config — Step 2: Feature Description
One codebase must serve zenmemes.com and chouse.club as separately branded
docs/plans/archive/multi_site_config_step2_feature_description.md Plans Plans and history
-
Multi-Site Config — Step 3: Development Plan
docs/plans/archive/multi_site_config_step3_development_plan.md Plans Plans and history
-
Multi-Site Config — Step 4: Implementation Summary
docs/plans/archive/multi_site_config_step4_implementation_summary.md Plans Plans and history
-
Paste Private Key From Clipboard Step 1 Solution Assessment
Users need to restore a browser posting identity by pasting private key material from the clipboard without sending it to the server.
docs/plans/archive/paste_private_key_from_clipboard_step1_solution_assessment.md Plans Plans and history
-
Paste Private Key From Clipboard Step 2 Feature Description
Users who have copied a browser posting private key need to restore that identity on /account/key/ without exposing private key material to the server.
docs/plans/archive/paste_private_key_from_clipboard_step2_feature_description.md Plans Plans and history
-
Paste Private Key From Clipboard Step 3 Development Plan
docs/plans/archive/paste_private_key_from_clipboard_step3_development_plan.md Plans Plans and history
-
Paste Private Key From Clipboard Step 4 Implementation Summary
docs/plans/archive/paste_private_key_from_clipboard_step4_implementation_summary.md Plans Plans and history
-
PHP Template Extraction Plan V1
This document describes how to move HTML out of application logic code while keeping the generated HTML easy to inspect in browser "view source".
docs/plans/archive/php_template_extraction_plan_v1.md Plans Plans and history
-
PHP Unicode Risk Detection Step 4 Implementation Summary
docs/plans/archive/php_unicode_risk_detection_step4_implementation_summary.md Plans Plans and history
-
Post Detached Signature Day-1 Recovery Plan V1
Restore the intended day-1 authenticity property for authored posts:
docs/plans/archive/post_detached_signature_day1_recovery_plan_v1.md Plans Plans and history
-
Post Public Key Link Step 1 Solution Assessment
Users need post pages to show a link to the author's public key file when available.
docs/plans/archive/post_public_key_link_step1_solution_assessment.md Plans Plans and history