docs: add Gitea workflows, issue/PR templates, README and licence notice

ci.yml calls `scripts/ci.sh` rather than restating the checks: a workflow that reimplements them becomes a second definition of "done", and the two drift. Android runs as a separate job. It fails when the SDK is absent while ci.sh skips it — a developer should not be blocked by a missing toolchain, but a silently skipped Android build in CI means regressions ship unnoticed. Every action is pinned to an exact version. LICENSE.md records that no licence is chosen yet, and why it is not a formality: the choice is upstream of the UI toolkit decision, since Slint is GPL-3.0. Co-Authored-By: Claude Code <noreply@anthropic.com>
2026-10-01 15:56:13 +03:00
parent 5073c7321d
commit af8b28f6c6
8 changed files with 784 additions and 0 deletions
@@ -0,0 +1,102 @@
+name: Platform limitation
+description: A case where the OS will not permit what CLAUDE.md asks for
+title: ""
+labels: ["limitation"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        CLAUDE.md section 6 lists the hard limits this project is known to have. This
+        template exists so a newly discovered one is recorded rather than quietly worked
+        around.
+
+        Section 0 rule 2: never fake a feature. If something cannot be enforced on a
+        platform, we implement the closest honest approximation and document the gap.
+        This form is how that documentation starts.
+
+  - type: dropdown
+    id: existing
+    attributes:
+      label: Is this already documented?
+      description: |
+        If it matches a numbered limitation in CLAUDE.md section 6, please comment on
+        that discussion instead of opening a new issue.
+      options:
+        - "No, this is new"
+        - "Yes, but our handling of it is wrong or incomplete"
+        - "Not sure"
+
+  - type: input
+    id: section
+    attributes:
+      label: Which section 6 limitation does this relate to?
+      description: "A number 1-8, or 'new'."
+    validations:
+      required: true
+
+  - type: dropdown
+    id: platform
+    attributes:
+      label: Platform
+      options:
+        - Linux (KDE Plasma / Wayland)
+        - Linux (KDE Plasma / X11)
+        - Linux (wlroots compositor)
+        - Linux (GNOME)
+        - Windows
+        - Android
+        - More than one
+
+  - type: textarea
+    id: reality
+    attributes:
+      label: What does the OS refuse to do?
+      description: |
+        The OS-level fact. Not "we could not figure it out" — what the platform makes
+        impossible or requires privileges we do not have.
+      placeholder: |
+        Wayland has no portable API for the focused window. Each compositor exposes its
+        own, and none is standard.
+    validations:
+      required: true
+
+  - type: textarea
+    id: workaround
+    attributes:
+      label: What do we do instead?
+      description: |
+        The closest honest approximation. If the answer is "nothing", say that. An
+        unimplemented limitation is a valid and common answer.
+      placeholder: "Process-based detection, which cannot show a block screen."
+    validations:
+      required: true
+
+  - type: textarea
+    id: privileges
+    attributes:
+      label: What privileges would a real fix need?
+      description: |
+        Root, CAP_SYS_ADMIN, an accessibility service, a browser extension, a Windows
+        service install? This determines whether the limitation is permanent or a
+        matter of permission design.
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: docs
+    attributes:
+      label: Documentation
+      options:
+        - label: This gap is documented in docs/LIMITATIONS.md
+          description: |
+            Required. An undocumented limitation is worse than an unimplemented one,
+            because the docs will imply a capability that does not exist.
+
+  - type: checkboxes
+    id: notblocked
+    attributes:
+      label: Confirm
+      options:
+        - label: |
+            This is not a request to block ADB, root access, safe mode, factory reset, or
+            OS recovery. Those are never blocked, by design (section 6.7, ADR-11).