# SyRF design handoff decisions — 6 October 2026

Source: owner discussion in this Codex session, following Claude's hand-back from PR #4096 at merged revision f6b172a28. Planning decisions only; feature implementation remains on hold. Nothing is sent to the design session by recording these answers.

## DQ-01 — Question editor for Classic projects

**Answer:** Chris answered “Yes” to using the same refreshed question editor for older and converted projects, while retaining the saving and assignment behaviour appropriate to each project mode.

**Status:** Approved, option (a): one editor with mode-appropriate capabilities. This does not silently introduce versioned publication, draft or assignment semantics into unconverted projects.

## DQ-02 — Where the question editor opens

**Status:** Approved by Chris, option (c): compact question list/tree with an editor beside it on wide screens, and a separate drill-in editor page on narrow screens.

The recommendation is a compact question tree with a side editor on wide screens, and a drill-in editor page on narrow screens. The proposed breakpoint is a design detail requiring validation, not an approved numerical threshold.

## DQ-03 — How design edits are kept in a draft

**Status:** Approved by Chris: automatic saving into the unpublished design draft, with clear save status, safe conflict handling and discard controls.

Recommendation: automatically save accepted field changes into the unpublished design draft, with save status, safe conflict handling and per-question discard controls. Saving a design draft does not publish changes to reviewers.

## DQ-04 — Reconciliation and design screens on phones

**Status:** Approved by Chris, option (b): usable responsive phone layouts with no feature removed, without a formal phone acceptance gate for reconciliation and design. The previously approved screening/annotation device acceptance requirements remain.

Full phone/tablet/desktop screening and annotation at launch is already approved. The remaining choice is whether reconciliation and question-design/admin screens must also pass a formal phone acceptance gate, or merely provide responsive layouts with all functionality available. The handoff recommends responsive functionality without adding a formal phone gate for these additional areas.

## DQ-46 — Naming answers and no-value answers

**Status:** Approved with revised terminology: Answer status describes the overall state; Reason no value is provided identifies configured explicit reasons; Other, please specify records an actual non-listed value.

The handoff recommends Answer as the umbrella term, Value or explicit No-value answer as the distinction, Unanswered for nothing recorded, Option only for predefined choices, and Not compared (unanswered) for missing agreement comparisons. Alternatives are Missing-data codes and Answer exceptions. All wording remains provisional until the owner decides.

### DQ-46 final owner clarification

Chris agreed the distinction after discussing custom reasons and non-listed values. Use Answer status for the overall state, covering Unanswered, answered with a listed or other specified value, and a configured explicit reason no value is provided. Use Reason no value is provided for that reason set, with No value to enter as the proposed reviewer action. Designers can configure defaults, custom reasons or catalogue sets and reason-specific metadata requirements. Other, please specify is a value-bearing answer with configured free text, not a missing-value reason. Preserve distinctions and configured stable identities in versions and exports. Naming of the action itself should be treated as illustrative unless separately confirmed.

All five class A questions are answered in this local discussion record. They still require integration into the repository pack and validation. Recording them does not send the pack or lift the implementation hold.

## DQ-09 — Scope of the inference beta

**Answer:** Chris said the recommendation makes sense: only rule-writing and inference require the beta.

**Status:** Approved, option (a): rule authoring/publication, rule evaluation and inferred results require explicit project beta opt-in; ordinary annotation and explicit group/classification recording follow their own availability and do not require inference-beta opt-in. This does not accelerate classification delivery or introduce a separate ordinary review workflow. It is a class B clarification, not a prerequisite to sending the design pack. Implementation remains on hold.