Quest Definition Schema Version 3.0.0

[uw-amy-bordenave]

Initial commit with added support for multiple quest answer dependencies.

Summary, generated by Claude 4.0:

---

Comparing schema-2.0.0.json with schema-3.0.0.json, here are the key changes:

Main Changes:

1. Schema Version Updated

• Version bumped from "2.0.0" to "3.0.0"

2. Complete Overhaul of quest_answer_dependency

In schema-2.0.0.json:

• Simple object structure
• Only supports single dependency (one question/answer pair)
• No description text
• No required properties defined

"quest_answer_dependency": {
  "description": "",
  "type": "object",
  "properties": {
    "question_id": { ... },
    "required_value": { ... }
  }
}

In schema-3.0.0.json:

• More powerful oneOf structure
• Supports both single AND multiple dependencies
• Comprehensive description explaining AND logic
• Required properties defined for both formats
• Added examples showing both usage patterns

"quest_answer_dependency": {
  "description": "Dependency conditions that must be met for this question to be visible. Can be a single condition object or an array of condition objects. When multiple conditions are provided, ALL conditions must be satisfied (AND logic).",
  "oneOf": [
    {
      "type": "object",
      "properties": { ... },
      "required": ["question_id", "required_value"]
    },
    {
      "type": "array",
      "items": { ... },
      "minItems": 1
    }
  ],
  "examples": [ ... ]
}

Summary:

The primary change is that schema-3.0.0.json enables multiple dependency conditions while schema-2.0.0.json only allowed a single dependency. This is a significant functional enhancement that allows questions to depend on multiple other questions simultaneously, with all conditions needing to be satisfied (AND logic).

---

[uw-amy-bordenave]

Scope: Update Long Form Quest Definition JSON Schema to 3.0.0 version with support for new quest_types: MultipleChoice and TextEntry, and multiple quest_answer_dependency

---

MultipleChoice is similar to ExclusiveChoice, but allows multiple options to be selected and enters them as a semicolon-delimited string. (ExclusiveChoice is radio buttons, MultipleChoice is checkboxes)

---

TextEntry is similar to Numeric, but allows for input of arbitrary text entry.

---

Multiple quest_answer_dependency enables things like "Answer additional questions?" + "(tactile_paving=yes)" → "What is the color of this tactile paving?"

[uw-amy-bordenave]

Apologies, I meant to switch branches - you can ignore f764013 and 6dda653 as they are unrelated to the topic of this PR and do not impact any of the relevant files.

[uw-amy-bordenave]

Flagging an issue: quest_answer_choices is incorrectly required for quest_type=Numeric

What is currently:

"allOf": [
  {
    "if": {
      "properties": { "quest_type": { "const": "TextEntry" } }
    },
    "else": {
      "required": ["quest_answer_choices"]
    }
  }
]

Should be:

"allOf": [
  {
    "if": {
      "properties": { 
        "quest_type": { 
          "enum": ["ExclusiveChoice", "MultipleChoice"] 
        } 
      }
    },
    "then": {
      "required": ["quest_answer_choices"]
    }
  }
]

This change flips the logic, so that quest_answer_choices is /only/ required for ExclusiveChoice and MultipleChoice, rather than exempting only TextEntry

[uw-amy-bordenave]

I'd also like us to add to this an improved quest_id numbering system, originally brought up by @shockwave656

Starting at 1XX, each element_type increments the first digit by +1.
Starting at X01, each child quest's quest_id increments the rest by +1.

Example:

element_type=Sidewalks
--- quest_id=101
--- quest_id=102
--- quest_id=103
element_type=Crossings
--- quest_id=201
--- ...
--- quest_id=209
--- quest_id=210
--- quest_id=211
element_type=Curbs
--- quest_id=301
--- quest_id=302

[cyrossignol]

Apologies, I meant to switch branches - you can ignore f764013 and 6dda653 as they are unrelated to the topic of this PR and do not impact any of the relevant files.

@uw-amy-bordenave No worries. I popped those two commits off of this branch.

[cyrossignol]

No issues stand out to me aside from the reversed logic that @uw-amy-bordenave already brought up!

[cyrossignol]

Plugging in @uw-amy-bordenave's comment.

[cyrossignol]

As you get more into GitHub, here's a friendly PR etiquette tip: I'd avoid mixing cosmetic and content changes in the same PR. The noisy diffs may divert attention from the "meat" of the PR. Good PRs usually have a narrow focus/scope.

In this case, I'm also a little worried that someone may inadvertently reverse the changes with some automated formatting tool—some editors run these automatically these days.

[uw-amy-bordenave]

Thanks for the heads up and the best-practices tip :)
In this case, that's exactly what happened - ran the Prettier formatter in VS Code.

[cyrossignol]

We may want to check in that Prettier config to this repo so tools don't fight with each other over formatting.

[uw-amy-bordenave]

Apologies, I meant to switch branches - you can ignore f764013 and 6dda653 as they are unrelated to the topic of this PR and do not impact any of the relevant files.

@uw-amy-bordenave No worries. I popped those two commits off of this branch.

Thanks. Completed these in #29.

[uw-amy-bordenave]

1. Synced with main in 2f7a95e
2. Implemented fix for quest_answer_choices logic in 2a83840 as mentioned above:

Flagging an issue: quest_answer_choices is incorrectly required for quest_type=Numeric

What is currently:

"allOf": [
  {
    "if": {
      "properties": { "quest_type": { "const": "TextEntry" } }
    },
    "else": {
      "required": ["quest_answer_choices"]
    }
  }
]

Should be:

"allOf": [
  {
    "if": {
      "properties": { 
        "quest_type": { 
          "enum": ["ExclusiveChoice", "MultipleChoice"] 
        } 
      }
    },
    "then": {
      "required": ["quest_answer_choices"]
    }
  }
]

This change flips the logic, so that quest_answer_choices is /only/ required for ExclusiveChoice and MultipleChoice, rather than exempting only TextEntry

[uw-amy-bordenave]

Disregard #25 (comment), we are holding off on redefining the quest_id approach until 4.0.0:

Short-term, as these continue to be created manually, the examples hint at the recommended numbering approach. (101, 102, ..., 201, 202, ..., 301, 302, ...)

Long-term, we'll want to use descriptive quest_ids that either mirror the StreetComplete approach (AddSidewalkSurface, AddCrossingMarkings, etc.) or mirror existing naming style for other fields (add_sidewalk_surface, or sidewalk_surface, or sidewalk:surface, or ...?) - either way, a change of quest_ids from number to string would need corresponding changes made to AVIV ScoutRoute (example: changing var questID: Int) which we can discuss at a later date.

---

Reviewed on call by @uw-amy-bordenave and @cyrossignol on 2025-09-23

@iamrajeshk Ready for final review from you.

[iamrajeshk]

Looks good to me. @uw-amy-bordenave Please merge it.