-
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
-
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 Plans and history
-
Post Public Key Link Step 3 Development Plan
docs/plans/archive/post_public_key_link_step3_development_plan.md Plans Plans and history
-
Post Public Key Link Step 4 Implementation Summary
docs/plans/archive/post_public_key_link_step4_implementation_summary.md Plans Plans and history
-
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 Plans and history
-
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 Plans and history
-
Public-Key Bootstrap Integrity Step 3 Development Plan
docs/plans/archive/public_key_bootstrap_integrity_step3_development_plan.md Plans Plans and history
-
Public-Key Bootstrap Integrity Step 4 Implementation Summary
docs/plans/archive/public_key_bootstrap_integrity_step4_implementation_summary.md Plans Plans and history
-
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 Plans and history
-
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 Plans and history
-
Public Key Visibility Step 3 Development Plan
docs/plans/archive/public_key_visibility_step3_development_plan.md Plans Plans and history
-
Public Key Visibility Step 4 Implementation Summary
docs/plans/archive/public_key_visibility_step4_implementation_summary.md Plans Plans and history
-
QDB Disabled Vote Button Appearance – Solution Assessment
For the qdb theme/site, when a voting button becomes disabled, I want it to change appearance to a gray color / less activatable looking color.
docs/plans/archive/qdb_disabled_vote_button_appearance_step1_solution_assessment.md Plans Plans and history
-
Reliable Page Delivery: Step 1 Solution Assessment
Cold mobile loads can visibly render before CSS arrives or wait behind the large OpenPGP bundle before basic controls work, while the current production static…
docs/plans/archive/reliable_page_delivery_step1_solution_assessment.md Plans Plans and history
-
Reliable Page Delivery: Step 2 Feature Description
Cold mobile visits can show an unstyled page and delay basic controls behind OpenPGP loading; deployment can also expose mismatched cached page resources or st…
docs/plans/archive/reliable_page_delivery_step2_feature_description.md Plans Plans and history