Current status — 2026-09-22
The broader interview-policy decision is deferred behind emitted-code quality. Its consequential-choice recommendation is still unapproved. The specific early invitation for real artifacts is separately accepted under #84; sample-data guidance is separately accepted under #83.
Remaining work
Do not block accepted #79/#80/#83/#84 work or silently treat this entire interview policy as approved.
Earlier scope and research (historical; the status above governs remaining work)
Parent: Drawing Board feedback tracker #43. Original observations 31, 32, 33, with the unwanted-field example 42 handled by the review packet.
Status: researched proposal; owner decision pending. The recommendation below does not retroactively approve assumptions in the old trials.
What was reported
Jelani’s trials differed in uniqueness rules, list ordering, optional Notes, and the treatment of logging dates. He also suggested asking about familiar habit-tracker features such as streaks and reminders. Some screenshots explicitly label choices as delegated and list exclusions, so it would be inaccurate to describe all choices as silent guessing. Complete interview transcripts are unavailable.
The Compiler followed materially different Plans. Determinism at Compilation does not make two independently authored product designs identical. The decision is which consequential ambiguity the planning agent should resolve, and which ordinary implementation choice it may make after delegation.
Current policy and original rationale
At Skills a001a24, the interview already:
- prioritizes graph, access, and client choices;
- distinguishes confirmed, delegated, excluded, open, and capability-gap items;
- prohibits inferring uniqueness from a label or promoting a common use case into an assumption;
- uses an internal ambiguity matrix rather than a one-message questionnaire;
- allows a coherent initial slice without resolving every imaginable future feature.
Those choices protect a short, incremental conversation and avoid shaping the app around whatever the Compiler happens to support. The old feedback does not justify reversing that rationale into a mandatory feature census.
Concrete questions that earn their cost
| Ambiguity |
Observable consequence |
Useful question |
| Unique Habit names |
Two different “Walk” habits may be rejected |
May a person have two habits with the same name? |
| One log per day |
A second entry may be rejected; dates need a meaning |
Is this one completion per habit per calendar day, or multiple events? |
| Future dates/backdating |
The user may be blocked from correction or planning |
Can a person correct earlier days, and should future logs be rejected? |
| Active-only logging |
Old records may become uneditable after a Habit is paused |
Is the restriction only when adding a log, or also when editing one? |
| Display order |
The same data may be hard to find |
Propose a normal list order and include it in review; ask when order carries product meaning. |
| Streaks/reminders |
Adds new product behavior and possibly delivery costs |
Offer only when the requested workflow calls for it; otherwise leave outside this slice. |
These are examples for training/evaluation, not six mandatory questions in every app. A date rule may also need a calendar/time-zone choice; that choice should not be invented from the developer’s computer or locale.
Prior art
Spec Kit’s clarification implementation prioritizes questions that materially change implementation or validation, excludes already-answered/trivial questions, and asks them sequentially. That supports the current First Draft direction. We need not copy its five-question cap, taxonomy, or additional artifact structure.
Rails supports explicit uniqueness and conditional validations; those APIs enforce the selected rule, not whether a product should have it. Database and framework conventions cannot answer “are two Walk habits allowed?” for the user.
Options and recommendation
- Ask about every common feature/default. Predictable coverage, but a long interview, feature creep, and stronger bias toward an app archetype.
- Consequential-choice triage with clear delegated defaults (recommended). Ask where a wrong choice changes allowed user behavior, ownership/access, or external effects. Propose ordinary presentation defaults compactly when delegated, and show them in the existing review. Do not introduce fields/features just because they are customary.
- Choose almost everything and rely on post-Compile editing. Fastest first output, but constraints and access mistakes can invalidate data or require avoidable rework.
One owner decision
Should we retain targeted consequential questions and explicit delegated defaults, and reject a mandatory common-feature checklist for every application?
Acceptance if approved
- Add realistic authoring examples for duplicate names, logging dates, omitted features, and an already-designed app; assess preservation and unnecessary question count.
- Ask one decision at a time when an owner answer is needed; do not re-interview choices already settled in design inputs.
- The read-back distinguishes requested behavior, delegated choices, and agent-proposed additions.
- Streaks/reminders and optional Note fields are not added merely because a sample app often has them.
- No new Compiler heuristic, domain-specific habit-tracker default, or universal FP option follows from this Skill-level decision.
Current status — 2026-09-22
The broader interview-policy decision is deferred behind emitted-code quality. Its consequential-choice recommendation is still unapproved. The specific early invitation for real artifacts is separately accepted under #84; sample-data guidance is separately accepted under #83.
Remaining work
Do not block accepted #79/#80/#83/#84 work or silently treat this entire interview policy as approved.
Earlier scope and research (historical; the status above governs remaining work)
Parent: Drawing Board feedback tracker #43. Original observations 31, 32, 33, with the unwanted-field example 42 handled by the review packet.
Status: researched proposal; owner decision pending. The recommendation below does not retroactively approve assumptions in the old trials.
What was reported
Jelani’s trials differed in uniqueness rules, list ordering, optional Notes, and the treatment of logging dates. He also suggested asking about familiar habit-tracker features such as streaks and reminders. Some screenshots explicitly label choices as delegated and list exclusions, so it would be inaccurate to describe all choices as silent guessing. Complete interview transcripts are unavailable.
The Compiler followed materially different Plans. Determinism at Compilation does not make two independently authored product designs identical. The decision is which consequential ambiguity the planning agent should resolve, and which ordinary implementation choice it may make after delegation.
Current policy and original rationale
At Skills
a001a24, the interview already:Those choices protect a short, incremental conversation and avoid shaping the app around whatever the Compiler happens to support. The old feedback does not justify reversing that rationale into a mandatory feature census.
Concrete questions that earn their cost
These are examples for training/evaluation, not six mandatory questions in every app. A date rule may also need a calendar/time-zone choice; that choice should not be invented from the developer’s computer or locale.
Prior art
Spec Kit’s clarification implementation prioritizes questions that materially change implementation or validation, excludes already-answered/trivial questions, and asks them sequentially. That supports the current First Draft direction. We need not copy its five-question cap, taxonomy, or additional artifact structure.
Rails supports explicit uniqueness and conditional validations; those APIs enforce the selected rule, not whether a product should have it. Database and framework conventions cannot answer “are two Walk habits allowed?” for the user.
Options and recommendation
One owner decision
Should we retain targeted consequential questions and explicit delegated defaults, and reject a mandatory common-feature checklist for every application?
Acceptance if approved