339 lines
9.0 KiB
Markdown
339 lines
9.0 KiB
Markdown
# Closer Question Rewrite Plan v9
|
|
|
|
## 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.
|
|
|
|
## Production Replacement Rule
|
|
|
|
Writing in batches does not permit shipping a partial pack.
|
|
|
|
During a rewrite:
|
|
|
|
1. Keep the last complete production JSON in place.
|
|
2. Draft each batch in a controlled workspace or clearly labeled WIP artifact.
|
|
3. Do not save a 25-question batch under the production filename.
|
|
4. Do not switch the production file to the old simple-pack shape.
|
|
5. Merge reviewed batches into the full `{ "category": ..., "questions": [...] }` structure.
|
|
6. Use integer depth `1`, `2`, or `3`.
|
|
7. Include `category_id` and `tags` on every production question.
|
|
8. Validate the complete pack.
|
|
9. Validate the full catalog across every production file.
|
|
10. Replace the production file only after both gates pass.
|
|
|
|
A continuation note such as `Next ID: rt_026` proves that work is incomplete. It is not permission to replace the live pack with the first 25 questions.
|
|
|
|
A patch manifest is also a work artifact. It must never replace the source pack.
|
|
|
|
## Standard Pack Workflow
|
|
|
|
For normal category packs of up to 150 questions:
|
|
|
|
1. Define the category purpose.
|
|
2. Define the main subtopics.
|
|
3. Write in batches of 25, or 15 to 20 for sensitive packs.
|
|
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 Pack Size and Full 150-Question Mix
|
|
|
|
Normal category packs may contain **up to 150 questions**. The limit is a ceiling, not a quota. Use fewer when the topic cannot support 150 strong, distinct prompts.
|
|
|
|
For a full 150-question mixed pack, use this planning target:
|
|
|
|
| Type | Count |
|
|
|---|---:|
|
|
| multi_choice | 90 |
|
|
| single_choice | 30 |
|
|
| scale | 15 |
|
|
| this_or_that | 10 |
|
|
| written | 5 |
|
|
|
|
Free and premium split:
|
|
|
|
* 45 free
|
|
* 105 premium
|
|
|
|
Written questions should normally total 0 to 5. They are not required when another question type works better. More than 5 requires a documented pack-specific reason and explicit approval.
|
|
|
|
## Special Pack Exception
|
|
|
|
Some product-specific packs may exceed the normal 150-question maximum or use a different type mix, but only when the exception is documented.
|
|
|
|
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 frozen weekday questions
|
|
* 11 free wildcard questions
|
|
* 511 total questions
|
|
* 86 free questions
|
|
* 425 premium questions
|
|
* 511 single_choice questions
|
|
|
|
This is a documented special-pack exception to the normal 150-question maximum.
|
|
|
|
Rules:
|
|
|
|
* every question must be single_choice
|
|
* every question must have 4 to 6 options
|
|
* 4 options preferred
|
|
* every weekday question must have exactly one weekday tag
|
|
* every wildcard question must use `mode_wildcard` and `daily_wildcard` and must not use 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 all 511 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 511 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 and wildcard questions 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 and all 11 wildcard questions.
|
|
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
|