-
Invite Destination Selector — Step 3: Development Plan
docs/plans/archive/invite_destination_selector_step3_development_plan.md Plans
-
Invite Destination Selector — Step 4: Implementation Summary
docs/plans/archive/invite_destination_selector_step4_implementation_summary.md Plans
-
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
-
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
-
Invite Session Authentication: Step 3 Development Plan
docs/plans/archive/invite_session_authentication_step3_development_plan.md Plans
-
Invite Session Authentication: Step 4 Implementation Summary
docs/plans/archive/invite_session_authentication_step4_implementation_summary.md Plans
-
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
-
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
-
iOS Users Page Cache Freshness Step 3 Development Plan
docs/plans/archive/ios_users_page_cache_freshness_step3_development_plan.md Plans
-
iOS Users Page Cache Freshness Step 4 Implementation Summary
docs/plans/archive/ios_users_page_cache_freshness_step4_implementation_summary.md Plans
-
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
-
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
-
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
-
LLM Prompt and Response Visibility Step 3 Development Plan
docs/plans/archive/llm_prompt_response_visibility_step3_development_plan.md Plans
-
LLM Prompt and Response Visibility Step 4 Implementation Summary
docs/plans/archive/llm_prompt_response_visibility_step4_implementation_summary.md Plans
-
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
-
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
-
Redeemable Board Invitations — Step 3: Development Plan
docs/plans/archive/lobby_board_invite_link_step3_development_plan.md Plans
-
Redeemable Board Invitations — Step 4: Implementation Summary
docs/plans/archive/lobby_board_invite_link_step4_implementation_summary.md Plans
-
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
-
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
-
Localhost Codex Task Handoff Step 3 Development Plan
docs/plans/archive/localhost_codex_task_handoff_step3_development_plan.md Plans
-
Localhost Codex Task Handoff Step 4 Implementation Summary
docs/plans/archive/localhost_codex_task_handoff_step4_implementation_summary.md Plans
-
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
-
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
-
Multi Provider LLM Config Step 3 Development Plan
docs/plans/archive/multi_provider_llm_config_step3_development_plan.md Plans
-
Multi Provider LLM Config Step 4 Implementation Summary
docs/plans/archive/multi_provider_llm_config_step4_implementation_summary.md Plans
-
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
-
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
-
Multi-Site Config — Step 3: Development Plan
docs/plans/archive/multi_site_config_step3_development_plan.md Plans
-
Multi-Site Config — Step 4: Implementation Summary
docs/plans/archive/multi_site_config_step4_implementation_summary.md Plans
-
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
-
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
-
Paste Private Key From Clipboard Step 3 Development Plan
docs/plans/archive/paste_private_key_from_clipboard_step3_development_plan.md Plans
-
Paste Private Key From Clipboard Step 4 Implementation Summary
docs/plans/archive/paste_private_key_from_clipboard_step4_implementation_summary.md Plans
-
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
-
PHP Unicode Risk Detection Step 4 Implementation Summary
docs/plans/archive/php_unicode_risk_detection_step4_implementation_summary.md Plans
-
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
-
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
-
Post Public Key Link Step 2 Feature Description
Users viewing a signed post need a direct way to inspect the author’s public key file.
docs/plans/archive/post_public_key_link_step2_feature_description.md Plans