feat: refactor sgclaw around zeroclaw compat runtime

third_party/zeroclaw/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,138 @@
+name: Bug Report
+description: Report a reproducible defect in ZeroClaw
+title: "[Bug]: "
+labels:
+  - bug
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to report a bug.
+        Please provide a minimal reproducible case so maintainers can triage quickly.
+        Do not include personal/sensitive data; redact and anonymize all logs/payloads.
+
+  - type: dropdown
+    id: component
+    attributes:
+      label: Affected component
+      options:
+        - runtime/daemon
+        - provider
+        - channel
+        - memory
+        - security/sandbox
+        - tooling/ci
+        - docs
+        - unknown
+    validations:
+      required: true
+
+  - type: dropdown
+    id: severity
+    attributes:
+      label: Severity
+      options:
+        - S0 - data loss / security risk
+        - S1 - workflow blocked
+        - S2 - degraded behavior
+        - S3 - minor issue
+    validations:
+      required: true
+
+  - type: textarea
+    id: current
+    attributes:
+      label: Current behavior
+      description: What is happening now?
+      placeholder: The process exits with ...
+    validations:
+      required: true
+
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected behavior
+      description: What should happen instead?
+      placeholder: The daemon should stay alive and ...
+    validations:
+      required: true
+
+  - type: textarea
+    id: reproduce
+    attributes:
+      label: Steps to reproduce
+      description: Please provide exact commands/config.
+      placeholder: |
+        1. zeroclaw onboard
+        2. zeroclaw daemon
+        3. Observe crash in logs
+      render: bash
+    validations:
+      required: true
+
+  - type: textarea
+    id: impact
+    attributes:
+      label: Impact
+      description: Who is affected, how often, and practical consequences (optional but helps triage).
+      placeholder: |
+        Affected users: ...
+        Frequency: always/intermittent
+        Consequence: ...
+    validations:
+      required: false
+
+  - type: textarea
+    id: logs
+    attributes:
+      label: Logs / stack traces
+      description: Paste relevant logs (redact secrets, personal identifiers, and sensitive data).
+      render: text
+    validations:
+      required: false
+
+  - type: input
+    id: version
+    attributes:
+      label: ZeroClaw version
+      placeholder: v0.1.0 / commit SHA
+    validations:
+      required: true
+
+  - type: input
+    id: rust
+    attributes:
+      label: Rust version
+      description: Required for runtime/build bugs; optional for docs/config issues.
+      placeholder: rustc 1.xx.x
+    validations:
+      required: false
+
+  - type: input
+    id: os
+    attributes:
+      label: Operating system
+      placeholder: Ubuntu 24.04 / macOS 15 / Windows 11
+    validations:
+      required: true
+
+  - type: dropdown
+    id: regression
+    attributes:
+      label: Regression?
+      options:
+        - Unknown
+        - Yes, it worked before
+        - No, first-time setup
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: checks
+    attributes:
+      label: Pre-flight checks
+      options:
+        - label: I reproduced this on the latest master branch or latest release.
+          required: true
+        - label: I redacted secrets, tokens, and personal data from all submitted content.
+          required: true

third_party/zeroclaw/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,11 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Security vulnerability report
+    url: https://github.com/zeroclaw-labs/zeroclaw/security/policy
+    about: Please report security vulnerabilities privately via SECURITY.md policy.
+  - name: Contribution guide
+    url: https://github.com/zeroclaw-labs/zeroclaw/blob/master/CONTRIBUTING.md
+    about: Please read contribution and PR requirements before opening an issue.
+  - name: PR workflow & reviewer expectations
+    url: https://github.com/zeroclaw-labs/zeroclaw/blob/master/docs/pr-workflow.md
+    about: Read risk-based PR tracks, CI gates, and merge criteria before filing feature requests.

third_party/zeroclaw/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,107 @@
+name: Feature Request
+description: Propose an improvement or new capability
+title: "[Feature]: "
+labels:
+  - enhancement
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for sharing your idea.
+        Please focus on user value, constraints, and rollout safety.
+        Do not include personal/sensitive data; use neutral project-scoped placeholders.
+
+  - type: input
+    id: summary
+    attributes:
+      label: Summary
+      description: One-line statement of the requested capability.
+      placeholder: Add a provider-level retry budget override for long-running channels.
+    validations:
+      required: true
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem statement
+      description: What user pain does this solve and why is current behavior insufficient?
+      placeholder: Teams operating in unstable networks cannot tune retries per provider...
+    validations:
+      required: true
+
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed solution
+      description: Describe preferred behavior and interfaces.
+      placeholder: Add `[provider.retry]` config and enforce bounds in config validation.
+    validations:
+      required: true
+
+  - type: textarea
+    id: non_goals
+    attributes:
+      label: Non-goals / out of scope
+      description: Clarify what should not be included in the first iteration (optional but helps scope discussion).
+      placeholder: No UI changes, no cross-provider dynamic adaptation in v1.
+    validations:
+      required: false
+
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives considered
+      description: What alternatives did you evaluate?
+      placeholder: Keep current behavior, use wrapper scripts, etc.
+    validations:
+      required: false
+
+  - type: textarea
+    id: acceptance
+    attributes:
+      label: Acceptance criteria
+      description: What outcomes would make this request complete? (optional — can be defined during triage)
+      placeholder: |
+        - Config key is documented and validated
+        - Runtime path uses configured retry budget
+        - Regression tests cover fallback and invalid config
+    validations:
+      required: false
+
+  - type: textarea
+    id: architecture
+    attributes:
+      label: Architecture impact
+      description: Which subsystem(s) are affected? (optional — maintainers will assess during triage)
+      placeholder: providers/, channels/, memory/, runtime/, security/, docs/ ...
+    validations:
+      required: false
+
+  - type: textarea
+    id: risk
+    attributes:
+      label: Risk and rollback
+      description: Main risk + how to disable/revert quickly (optional — can be defined during planning).
+      placeholder: Risk is ... rollback is ...
+    validations:
+      required: false
+
+  - type: dropdown
+    id: breaking
+    attributes:
+      label: Breaking change?
+      options:
+        - "No"
+        - "Yes"
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: hygiene
+    attributes:
+      label: Data hygiene checks
+      options:
+        - label: I removed personal/sensitive data from examples, payloads, and logs.
+          required: true
+        - label: I used neutral, project-focused wording and placeholders.
+          required: true