307 lines
7.2 KiB
Markdown
307 lines
7.2 KiB
Markdown
# QUESTION_REWRITE_PLAN.md
|
|
|
|
## Purpose
|
|
|
|
This plan defines how to rewrite Closer question packs without producing valid but dead content.
|
|
|
|
The goal is not just clean JSON.
|
|
|
|
The goal is questions real couples want to answer.
|
|
|
|
## Standard Pack Workflow
|
|
|
|
For normal 250 question category packs:
|
|
|
|
1. Define the category purpose.
|
|
2. Define the main subtopics.
|
|
3. Write in batches of 40 to 50.
|
|
4. Review tone and repetition after each batch.
|
|
5. Assign types, access, and depth.
|
|
6. Validate schema.
|
|
7. Check duplicate question text.
|
|
8. Check duplicate option lists.
|
|
9. Read random questions out loud.
|
|
10. Fix weak items before shipping.
|
|
|
|
## Standard 250 Question Mix
|
|
|
|
| Type | Count |
|
|
|---|---:|
|
|
| multi_choice | 140 |
|
|
| single_choice | 50 |
|
|
| scale | 35 |
|
|
| this_or_that | 15 |
|
|
| written | 10 |
|
|
|
|
Free and premium split:
|
|
|
|
* 75 free
|
|
* 175 premium
|
|
|
|
## Special Pack Exception
|
|
|
|
Some packs are product-specific and may override the standard 250 question mix.
|
|
|
|
A special pack must document:
|
|
|
|
* pack id
|
|
* file name
|
|
* expected count
|
|
* allowed question types
|
|
* free count
|
|
* premium count
|
|
* required tags
|
|
* reason for the exception
|
|
|
|
Special packs still must pass tone, duplicate, option, schema, and sample review.
|
|
|
|
|
|
## Research Pass Before Writing Daily Questions
|
|
|
|
Before writing or rewriting a daily pack, review current examples from relationship question apps, conversation-card games, date-night prompt lists, and relationship research summaries.
|
|
|
|
Do not copy questions.
|
|
|
|
Extract patterns only:
|
|
|
|
* what makes the question playful
|
|
* what makes the answer quick
|
|
* what categories repeat across good examples
|
|
* where prompts become too deep, clinical, or boring
|
|
* how flirty prompts stay consent-based and low pressure
|
|
* how games use choice, surprise, humor, and story
|
|
|
|
Turn that research into a short style note before generating questions.
|
|
|
|
The style note must include:
|
|
|
|
* approved question mechanics
|
|
* banned stale mechanics
|
|
* approved option types
|
|
* banned option types
|
|
* sample good prompts
|
|
* sample bad prompts
|
|
|
|
Do not scale the pack until the style note is written.
|
|
|
|
## Daily Single Choice Weekday Pack
|
|
|
|
Pack id:
|
|
|
|
```text
|
|
daily_single_choice_weekly_v1
|
|
```
|
|
|
|
Current compatibility file name:
|
|
|
|
```text
|
|
daily_fun_multiple_choice_v3.json
|
|
```
|
|
|
|
Recommended future file name:
|
|
|
|
```text
|
|
daily_single_choice_weekly_v1.json
|
|
```
|
|
|
|
Expected counts:
|
|
|
|
* 500 total questions
|
|
* 75 free questions
|
|
* 425 premium questions
|
|
* 500 single_choice questions
|
|
|
|
Rules:
|
|
|
|
* every question must be single_choice
|
|
* every question must have 4 to 6 options
|
|
* 4 options preferred
|
|
* every question must have a weekday tag
|
|
* every option must answer the prompt
|
|
* no therapy worksheet tone
|
|
* no wellness survey tone
|
|
* no household admin tone
|
|
* no chore-heavy answer sets
|
|
* no repeated exact option lists
|
|
|
|
Weekday tags:
|
|
|
|
* daily_monday_mood_check
|
|
* daily_tuesday_tiny_win
|
|
* daily_wednesday_real_one
|
|
* daily_thursday_laugh
|
|
* daily_friday_flirty
|
|
* daily_saturday_side_quest
|
|
* daily_sunday_slow_burn
|
|
|
|
## Daily Fun-First Rule
|
|
|
|
Daily questions must be fun before they are useful.
|
|
|
|
If a daily prompt mostly helps the couple manage chores, bedtime, errands, dishes, bills, or logistics, rewrite it toward one of these:
|
|
|
|
* a tiny date
|
|
* a joke
|
|
* a snack
|
|
* a flirt
|
|
* a mini adventure
|
|
* a sweet surprise
|
|
* a playful choice
|
|
* a cute debate
|
|
* a small shared moment
|
|
|
|
Do not approve a daily batch just because it is concrete.
|
|
|
|
Concrete can still be boring.
|
|
|
|
A daily batch should feel like something users would want to tap tonight.
|
|
|
|
## Daily Production Loop
|
|
|
|
Do not write or rewrite 500 daily questions in one pass.
|
|
|
|
Use a bounded loop. The goal is quality control, not infinite polishing until everyone forgets why the app exists.
|
|
|
|
### Patch Mode Required
|
|
|
|
Daily updates must default to patch mode.
|
|
|
|
Patch mode means:
|
|
|
|
1. Review the full pack.
|
|
2. Mark only failing question IDs.
|
|
3. Fix only the marked IDs.
|
|
4. Preserve passing questions exactly.
|
|
5. Preserve metadata unless metadata is the failure.
|
|
6. Review the patched questions again.
|
|
7. Repeat only for IDs that still fail.
|
|
|
|
Do not rewrite all 500 because some questions failed.
|
|
|
|
Do not rewrite a whole weekday unless the mass rewrite exception applies.
|
|
|
|
### Mass Rewrite Exception
|
|
|
|
A mass rewrite is allowed only when more than 60 percent of a weekday or pack fails for the same root cause.
|
|
|
|
The review report must include:
|
|
|
|
* failure percentage
|
|
* shared root cause
|
|
* why patching individual IDs is worse
|
|
* fields that will be preserved
|
|
* sample-gate results after the rewrite
|
|
|
|
Without this report, mass rewriting is not allowed.
|
|
|
|
### Fix Scope
|
|
|
|
Every marked question must include one fix scope:
|
|
|
|
* `prompt_only`
|
|
* `options_only`
|
|
* `prompt_and_options`
|
|
* `metadata_only`
|
|
* `delete_or_replace`
|
|
|
|
Normal tone fixes should usually be `prompt_only`, `options_only`, or `prompt_and_options`.
|
|
|
|
Do not change access, depth, tags, or IDs unless the fix scope says metadata is involved.
|
|
|
|
### Per Weekday Loop
|
|
|
|
For each weekday theme:
|
|
|
|
1. Write or rewrite 20 questions.
|
|
2. Review the 20 questions out loud.
|
|
3. Mark every weak question with a reason.
|
|
4. Fix only the marked questions.
|
|
5. Review the fixed questions again.
|
|
6. Continue only when at least 18 of 20 pass.
|
|
7. Continue only when at least 16 of 20 feel fun, playful, sweet, flirty, silly, or date-like.
|
|
8. Expand that weekday theme in batches of 20 to 30.
|
|
9. Repeat mark, fix, review after each batch.
|
|
10. Move to the next weekday only after the current weekday passes.
|
|
|
|
### Pass Standard
|
|
|
|
A daily question passes only if:
|
|
|
|
* it sounds like something normal people would say
|
|
* it can be answered in under 10 seconds
|
|
* it feels like a couples game
|
|
* it is fun before merely useful
|
|
* it is concrete and tied to real life
|
|
* every option answers the exact prompt
|
|
* every option is a complete answer
|
|
* the weekday theme is clear
|
|
* the wording does not feel generated
|
|
* the answer set is not household admin
|
|
|
|
### Required Marking Reasons
|
|
|
|
When marking a daily question, use one or more of these reasons:
|
|
|
|
* therapy_voice
|
|
* wellness_voice
|
|
* household_admin
|
|
* not_fun
|
|
* abstract_prompt
|
|
* awkward_split_phrase
|
|
* repeated_stem
|
|
* option_mismatch
|
|
* fragment_options
|
|
* too_generic
|
|
* weird_option
|
|
* weak_weekday_fit
|
|
* filler_question
|
|
* too_random
|
|
* mechanic_overuse
|
|
* patch_scope_violation
|
|
|
|
### Final Pack Gate
|
|
|
|
After all weekdays are drafted:
|
|
|
|
1. Run schema and count validation.
|
|
2. Run duplicate question and duplicate option-list checks.
|
|
3. Check repeated openers.
|
|
4. Check repeated option text.
|
|
5. Read 10 random questions from each weekday.
|
|
6. Mark anything weak.
|
|
7. Fix marked questions.
|
|
8. Run a second random sample from each weekday.
|
|
9. Fix only marked sample items.
|
|
10. Run another sample if anything changed.
|
|
11. Ship only if the second sample passes cleanly and remaining hard flags are 0.
|
|
|
|
Do not skip the final sample gate.
|
|
|
|
A pack can be technically valid and still sound like a relationship app generated by a toaster with abandonment issues.
|
|
|
|
## Rewrite Rules
|
|
|
|
When rewriting weak questions:
|
|
|
|
* keep the original category purpose
|
|
* remove therapy wording
|
|
* remove abstract phrasing
|
|
* use simpler language
|
|
* make the prompt answerable
|
|
* make options balanced
|
|
* avoid fake healthy answers
|
|
* avoid repeated stems
|
|
* keep the emotional intensity appropriate
|
|
|
|
## Final Deliverables
|
|
|
|
Each rewrite should provide:
|
|
|
|
* updated JSON
|
|
* validation report
|
|
* marked fixes CSV or JSON
|
|
* patched fixes CSV or JSON
|
|
* remaining flags CSV or JSON
|
|
* short review findings
|
|
* apply instructions
|