Previous value: -"The complete SpecPilot answer set to generate from - everything collected through specpilot_next_questions. projectName and projectDescription are required; every other field falls back to a sensible default."New value: +"The complete SpecPilot answer set to generate from - everything collected through specpilot_next_questions, whose schema describes each field. projectName and projectDescription are required; every other field falls back to a sensible default."

Removed value: -"The access control model. Drives the security spec auth/authorization section and the permission model."

Removed value: -"Anything further on accessibility or constraints, in free text."

Removed value: -"Roughly how many active users are expected, as a range."

Removed value: -"Target API response time."

Removed value: -"API style - REST, GraphQL, gRPC or tRPC. Shapes how the architecture spec documents client-server communication."

Removed value: -"Auth approach - a protocol built in-house (JWT/OAuth/SAML) or a managed service (Clerk, Auth0, Firebase). Feeds the security spec."

Removed value: -"Availability SLA target as a fraction of uptime; higher percentages allow far less downtime per year."

Removed value: -"How long the build is expected to take."

Removed value: -"CI/CD practices - automatically running tests and deploying on every change."

Removed value: -"Compliance regimes that apply - GDPR, HIPAA, SOC 2. Pick by the actual situation (EU users, health data, payments), since getting it wrong has legal consequences."

Removed value: -"More detail on whatever was named in technicalConstraints."

Removed value: -"A user type in free text, when none of the userTypes options fit."

Removed value: -"How conflicting local and server state gets reconciled once the device is back online."

Removed value: -"Database kinds in use - SQL, NoSQL, cache/key-value, vector. As many as apply."

Removed value: -"Where this ships - cloud hosting, a package registry, a browser store. The option list depends on the project type."

Removed value: -"The developer GitHub handle. Optional; it namespaces generated task IDs (e.g. CD-jsmith-001). Infer from git config or the origin remote."

Removed value: -"The editor or AI IDE in use - claudecode, cursor, copilot, codex, windsurf. You are the IDE, so set this yourself; it decides which rules and config files are generated."

Removed value: -"Third-party integrations keyed by category, e.g. { payments: [\"stripe\"] }. Only categories relevant to the project type apply."

Removed value: -"True for a greenfield project, false when adding onto an existing codebase. Decides which onboarding analysis is generated at the end."

Removed value: -"Primary language, when it should override what SpecPilot infers from the repo."

Removed value: -"On-device stores backing offline support. Leave empty when offline is not needed."

Removed value: -"What this project explicitly will NOT do. Becomes the non-goals section of the specs."

Removed value: -"Whether this has to work offline. Set automatically when localDatabases is non-empty."

Removed value: -"External APIs or services not covered by integrations."

Removed value: -"Platforms this should run on, e.g. web, ios, android, desktop. Infer from the dependency manifests and repo layout."

Removed value: -"Project archetype. Normally inferred from projectDescription when it exactly matches a returned chip label - send it only if you already know it."

Removed value: -"One line saying what the project is. Required by specpilot_generate_specs. Sending one of the chip labels returned by specpilot_next_questions verbatim is what infers projectCategory and gates every later question; free prose infers nothing."

Removed value: -"Short name for the project. Required by specpilot_generate_specs. Infer from the package manifest or the folder name."

Removed value: -"Whether anything updates live without a refresh. Set automatically when realtimeTypes is non-empty."

Removed value: -"Realtime transports - WebSockets, SSE, polling. Leave empty when nothing needs to update live."

Removed value: -"Expected scale of the system. Drives infrastructure and architecture choices."

Removed value: -"Security measures to plan for - encryption, rate limiting, audit logging."

Removed value: -"Cross-cutting concerns that apply, such as accessibility, internationalisation or offline support."

Removed value: -"Architecture pattern - monolith, modular monolith, or microservices."

Removed value: -"How many people are building this."

Removed value: -"Hard constraints - budget, existing infrastructure, legacy systems, a fixed deadline."

Removed value: -"Testing approaches this project will use."

Removed value: -"Who is going to use this system, e.g. end users, admins, internal staff."

Added value: +"The complete SpecPilot answer set to generate from - everything collected through specpilot_next_questions. projectName and projectDescription are required; every other field falls back to a sensible default."

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "fileCount": {
+      "description": "How many files were generated.",
+      "type": "number"
+    },
+    "files": {
+      "description": "Every file to write - spec files, the .specs/ README, and IDE or repository config.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "content": {
+            "description": "Full file contents to write verbatim.",
+            "type": "string"
+          },
+          "path": {
+            "description": "Path to write, relative to the repository root. Do not rename it.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "path",
+          "content"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "nextSteps": {
+      "description": "What to do after writing the files, including where each path belongs.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "files",
+    "fileCount",
+    "nextSteps"
+  ],
+  "type": "object"
+}

Added value: +"The access control model. Drives the security spec auth/authorization section and the permission model."

Added value: +"Anything further on accessibility or constraints, in free text."

Added value: +"Roughly how many active users are expected, as a range."

Added value: +"Target API response time."

Added value: +"API style - REST, GraphQL, gRPC or tRPC. Shapes how the architecture spec documents client-server communication."

Added value: +"Auth approach - a protocol built in-house (JWT/OAuth/SAML) or a managed service (Clerk, Auth0, Firebase). Feeds the security spec."

Added value: +"Availability SLA target as a fraction of uptime; higher percentages allow far less downtime per year."

Added value: +"How long the build is expected to take."

Added value: +"CI/CD practices - automatically running tests and deploying on every change."

Added value: +"Compliance regimes that apply - GDPR, HIPAA, SOC 2. Pick by the actual situation (EU users, health data, payments), since getting it wrong has legal consequences."

Added value: +"More detail on whatever was named in technicalConstraints."

Added value: +"A user type in free text, when none of the userTypes options fit."

Added value: +"How conflicting local and server state gets reconciled once the device is back online."

Added value: +"Database kinds in use - SQL, NoSQL, cache/key-value, vector. As many as apply."

Added value: +"Where this ships - cloud hosting, a package registry, a browser store. The option list depends on the project type."

Added value: +"The developer GitHub handle. Optional; it namespaces generated task IDs (e.g. CD-jsmith-001). Infer from git config or the origin remote."

Added value: +"The editor or AI IDE in use - claudecode, cursor, copilot, codex, windsurf. You are the IDE, so set this yourself; it decides which rules and config files are generated."

Added value: +"Third-party integrations keyed by category, e.g. { payments: [\"stripe\"] }. Only categories relevant to the project type apply."

Added value: +"True for a greenfield project, false when adding onto an existing codebase. Decides which onboarding analysis is generated at the end."

Added value: +"Primary language, when it should override what SpecPilot infers from the repo."

Added value: +"On-device stores backing offline support. Leave empty when offline is not needed."

Added value: +"What this project explicitly will NOT do. Becomes the non-goals section of the specs."

Added value: +"Whether this has to work offline. Set automatically when localDatabases is non-empty."

Added value: +"External APIs or services not covered by integrations."

Added value: +"Platforms this should run on, e.g. web, ios, android, desktop. Infer from the dependency manifests and repo layout."

Added value: +"Project archetype. Normally inferred from projectDescription when it exactly matches a returned chip label - send it only if you already know it."

Added value: +"One line saying what the project is. Required by specpilot_generate_specs. Sending one of the chip labels returned by specpilot_next_questions verbatim is what infers projectCategory and gates every later question; free prose infers nothing."

Added value: +"Short name for the project. Required by specpilot_generate_specs. Infer from the package manifest or the folder name."

Added value: +"Whether anything updates live without a refresh. Set automatically when realtimeTypes is non-empty."

Added value: +"Realtime transports - WebSockets, SSE, polling. Leave empty when nothing needs to update live."

Added value: +"Expected scale of the system. Drives infrastructure and architecture choices."

Added value: +"Security measures to plan for - encryption, rate limiting, audit logging."

Added value: +"Cross-cutting concerns that apply, such as accessibility, internationalisation or offline support."

Added value: +"Architecture pattern - monolith, modular monolith, or microservices."

Added value: +"How many people are building this."

Added value: +"Hard constraints - budget, existing infrastructure, legacy systems, a fixed deadline."

Added value: +"Testing approaches this project will use."

Added value: +"Who is going to use this system, e.g. end users, admins, internal staff."