Clarify web-native and web-only project options

DECISIONS.md

@@ -30,10 +30,14 @@ policies and resolves ambiguities in the original `genairosity.md` proposal.
     initial process. Ambiguous evidence requires review.
 11. **FOSS default.** New project code defaults to AGPL-3.0-or-later. A documented
     maintainer decision can approve another FOSS license. Preserve inherited licenses.
-12. **Performance and usability.** Rust preferred where suitable; Linux-first desktop
-    support and Android-first mobile support where applicable. Useful, approachable
-    workflows matter. Server components must be FOSS and self-hostable. AI features
-    should allow configurable APIs and local endpoints.
+12. **Performance and usability.** Choose platforms and stacks to suit the workflow.
+    Web-native applications, including web-only software, are fully valid choices;
+    native desktop or mobile clients are not required. Rust is preferred where
+    suitable, not mandatory, including for web projects. Linux-first applies when
+    building desktop clients; Android-first applies when building mobile clients.
+    These priorities do not require native clients for a web application. Useful,
+    approachable workflows matter. Server components must be FOSS and self-hostable.
+    AI features should allow configurable APIs and local endpoints.
 13. **Initial candidates.** CapCut, offline coding agent, Bluebeam Revu, LabVIEW, and
     FileMaker are unranked investigations, not implementation announcements.
 14. **Ownership.** Founding projects normally live under `508-dev`; explicitly approved

README.md

@@ -66,9 +66,11 @@ publication or registration. See [project setup](docs/project-setup.md).
 ## Principles and licensing
 
 Legal and independently implemented; FOSS throughout, including self-hostable
-server components; performant; accessible to ordinary users; Linux-first for
-cross-platform desktop software and Android-first for mobile where appropriate.
-Rust is preferred when it fits. Avoid duplicating strong existing FOSS efforts.
+server components; performant; accessible to ordinary users. Web-native applications,
+including web-only software, are fully valid choices; native clients are not required.
+Linux-first applies to desktop clients and Android-first to mobile clients, not as a
+requirement to build either. Rust is preferred when it fits, not mandatory, including
+for web projects. Avoid duplicating strong existing FOSS efforts.
 AI features, if any, should support configurable providers and local endpoints.
 
 Original hub code, documentation, and project starter: **AGPL-3.0-or-later**.

content/principles.md

@@ -23,8 +23,11 @@ A documented process is not a blanket legal guarantee. Doubtful inputs need revi
 ## Good enough for everyday life
 
 Performance, accessible design, and approachable workflows are core requirements.
-Rust is preferred where appropriate. Linux is a first-class desktop platform;
-Android is the mobile priority where applicable. Cross-platform support follows the scope.
+Web-native applications, including web-only software, are fully valid choices;
+native desktop or mobile clients are not required. Rust is preferred where appropriate,
+not mandatory, including for web projects. When building native clients, Linux is a
+first-class desktop platform and Android is the mobile priority. Platform and stack
+choices follow the workflow and scope.
 
 ## Build where the gap is
 

devkit/README.md

@@ -14,8 +14,13 @@ not certify completeness, legal compliance, or eligibility for registration.
 
 ## Optional stack choices
 
-Choose the stack after scope is understood; Rust is preferred when suitable. Document
-tradeoffs and real verification commands. Add ordinary CI once there is code to check.
+Choose platforms and the stack after scope is understood. Web-native applications,
+including web-only software, are fully valid choices and do not need native clients.
+Rust is preferred when suitable, not mandatory, including for web projects; choosing
+another language or a web-only platform does not require a policy exception.
+Linux-first and Android-first priorities apply only when building desktop and mobile
+clients respectively. Document tradeoffs and real verification commands.
+Add ordinary CI once there is code to check.
 Do not add cloud model execution. Keep server components FOSS and self-hostable.
 
 Preserve supply-chain conventions in selected stacks:

devkit/VERSION

@@ -1 +1 @@
-0.1.0
+0.1.1

devkit/template/AGENTS.md

@@ -20,7 +20,12 @@ Document verification in docs/verification.md. Run python3 scripts/check-project
 and relevant checks before a PR. Report limitations honestly; structural success is
 not substantive approval. Keep secrets and .context/ out of git.
 
-Rust is preferred where it fits; stack choices require a documented reason. Keep
+Choose platforms and stacks for the workflow. Web-native applications, including
+web-only software, are fully valid choices; do not infer a requirement for native
+desktop or mobile clients. Rust is preferred where it fits, not mandatory, including
+for web projects. Linux-first applies when building desktop clients; Android-first
+applies when building mobile clients. Document platform and stack tradeoffs; choosing
+another language or a web-only platform does not require a policy exception. Keep
 FOSS licenses/notices, locked installs, and supported dependency cooldowns. Update
 README and verification commands when a stack is selected. Do not change hub
 membership or status except through an explicitly reviewed hub PR.

devkit/template/docs/charter.md

@@ -19,10 +19,14 @@ Pending research: record alternatives, gaps, and whether contributing upstream i
 
 ## Platforms, usability, and performance
 
-Pending scope decision: Linux-first desktop or Android-first mobile where applicable;
-choose other platforms and measurable targets based on the workflow. Rust is preferred
-where appropriate. Server components must be FOSS and self-hostable. AI features,
-if any, should support configurable providers and local endpoints.
+Pending scope decision: choose platforms and measurable targets based on the workflow.
+Web-native applications, including web-only software, are fully valid choices; native
+clients are not required. Linux-first applies when building desktop clients;
+Android-first applies when building mobile clients. Rust is preferred where appropriate,
+not mandatory, including for web projects. Document platform and stack tradeoffs;
+choosing another language or a web-only platform does not require a policy exception.
+Server components must be FOSS and self-hostable. AI features, if any, should support
+configurable providers and local endpoints.
 
 ## Ownership and mission