-
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
-
Post Public Key Link Step 3 Development Plan
docs/plans/archive/post_public_key_link_step3_development_plan.md Plans
-
Post Public Key Link Step 4 Implementation Summary
docs/plans/archive/post_public_key_link_step4_implementation_summary.md Plans
-
Public-Key Bootstrap Integrity Step 1 Solution Assessment
Automatically created bootstrap posts are unsigned and hidden, which makes identity association, authorship verification, account completeness, and repeated se…
docs/plans/archive/public_key_bootstrap_integrity_step1_solution_assessment.md Plans
-
Public-Key Bootstrap Integrity Step 2 Feature Description
New accounts receive a hidden bootstrap post that is linked to their public key but is not signed, so visitors cannot distinguish identity association from cry…
docs/plans/archive/public_key_bootstrap_integrity_step2_feature_description.md Plans
-
Public-Key Bootstrap Integrity Step 3 Development Plan
docs/plans/archive/public_key_bootstrap_integrity_step3_development_plan.md Plans
-
Public-Key Bootstrap Integrity Step 4 Implementation Summary
docs/plans/archive/public_key_bootstrap_integrity_step4_implementation_summary.md Plans
-
Public Key Visibility Step 1 Solution Assessment
Visitors should be able to view a user’s public key(s) from an approved profile, an unapproved profile, or that profile’s bootstrap post.
docs/plans/archive/public_key_visibility_step1_solution_assessment.md Plans
-
Public Key Visibility Step 2 Feature Description
Approved and unapproved profile pages already expose a user’s public key under advanced technical details, but a visitor viewing the user’s bootstrap post has…
docs/plans/archive/public_key_visibility_step2_feature_description.md Plans