@hanzlaa/rcode 3.6.15 → 4.0.0

package/rihal/templates/milestone.md

@@ -1,149 +0,0 @@
-# Milestone Template
-
-<!-- P2: Omit any section with nothing substantive. Empty sections are noise. Omit STATE.md blockers/workstreams if none active. Omit REQUIREMENTS.md out-of-scope if it doesn't constrain execution. -->
-
-Use this template when starting a new milestone with `/rihal-new-milestone`.
-
-## ROADMAP.md
-
-```markdown
-# Milestone: {NAME}
-
-**Started:** {ISO_DATE}
-**Status:** PLANNING
-
-## Goals
-
-Measurable outcomes for this milestone (3-5 items):
-
-- Goal 1: [Specific, measurable outcome]
-- Goal 2: [Specific, measurable outcome]
-- Goal 3: [Specific, measurable outcome]
-
-## Phases
-
-High-level breakdown of work:
-
-| # | Name | Status | Owner | Completion |
-|---|------|--------|-------|------------|
-| 1 | {Phase Name} | PLAN | {Owner} | 0% |
-
-## Success Criteria
-
-What does "done" look like?
-
-- All goals achieved
-- All phases completed
-- No critical blockers outstanding
-
-## Kill Criteria
-
-Under what conditions do we stop this milestone?
-
-- No engagement after 60 days
-- Core technical blocker cannot be resolved
-- Strategic shift makes it obsolete
-```
-
-## STATE.md
-
-```markdown
-# Milestone State: {NAME}
-
-**Last Updated:** {ISO_DATE}
-**Current Phase:** PLANNING
-
-## Decisions Made
-
-Log of all significant decisions with context:
-
-| Decision | Rationale | Date | Owner |
-|----------|-----------|------|-------|
-| {Decision} | {Why} | {Date} | {Person} |
-
-## Blockers
-
-Active blockers preventing progress:
-
-- [Blocker 1] (since date, assigned to person, depends on X)
-- [Blocker 2] (since date, assigned to person, depends on Y)
-
-## Active Workstreams
-
-Parallel work streams running concurrently:
-
-- Workstream 1: {Description} (owner, expected completion)
-- Workstream 2: {Description} (owner, expected completion)
-
-## Quick Tasks Completed
-
-Small items completed outside the main phase structure:
-
-| Task | Date | Owner |
-|------|------|-------|
-| {Task} | {Date} | {Person} |
-
-## Metrics
-
-Current health metrics:
-
-- Phase completion: X%
-- Velocity: {points/day}
-- Risk level: {HIGH|MEDIUM|LOW}
-```
-
-## REQUIREMENTS.md
-
-```markdown
-# Requirements: {NAME}
-
-**Updated:** {ISO_DATE}
-
-## User Stories
-
-Features requested from user perspective:
-
-```gherkin
-As a {user}, I want {capability} so that {benefit}
-Acceptance Criteria:
-  - [ ] Criterion 1
-  - [ ] Criterion 2
-```
-
-## Technical Specifications
-
-Implementation-level details:
-
-- {Spec 1}
-- {Spec 2}
-
-## Acceptance Criteria
-
-How do we validate completion?
-
-- [ ] Criteria 1 met and tested
-- [ ] Criteria 2 met and tested
-
-## Out of Scope
-
-What are we explicitly NOT doing?
-
-- Out of scope item 1
-- Out of scope item 2
-
-## Dependencies
-
-What must be done before this milestone can succeed?
-
-- External dependency 1
-- Internal dependency 1
-```
-
-## Best Practices
-
-1. **Keep goals measurable** — "Increase signup rate by 15%" not "improve signup"
-2. **Name owners for every phase** — accountability matters
-3. **Update STATE.md weekly** — don't let decisions get lost
-4. **Kill criteria first** — know what stops work before starting
-5. **Scope creep signal** — if new phases appear, escalate
-6. **Document assumptions** — every phase starts with assumptions listed

package/rihal/templates/projects/api-backend/PROJECT.md

@@ -1,37 +0,0 @@
-# {{project_name}} — API Backend
-
-**Template:** api-backend
-**Created:** {{date}}
-
-## What we're building
-A headless API for {{use_case}}. Consumers are other services, internal apps, or third-party integrations — not end users directly.
-
-## API surface
-- **Protocol:** REST / GraphQL / gRPC — pick one, justify in an ADR
-- **Versioning strategy:** {{versioning}} (URL-prefix vs header vs dated)
-- **Auth:** API keys + scoped tokens
-
-## Primary consumers
-- {{consumer_1}}
-- {{consumer_2}}
-
-## Performance targets
-- p50 latency: {{p50}} · p95: {{p95}} · p99: {{p99}}
-- Throughput: {{rps}} req/s sustained
-- Availability: {{slo}}
-
-## Non-negotiables
-- Every endpoint is idempotent or explicitly documented as non-idempotent
-- Breaking changes ship under a new version — never mutate existing endpoints
-- Errors follow a consistent schema (code, message, request_id)
-
-## Explicitly out of scope
-- Frontend / dashboards (separate project)
-- Self-serve signup UI
-
-## Key risks
-- Scope drift into full-product features → resist
-- Early API shape locks in; expensive to change once consumers integrate
-
-## Evolution
-_(Updated after each phase completion by `/rihal-execute`.)_

package/rihal/templates/projects/api-backend/template.yaml

@@ -1,17 +0,0 @@
-name: api-backend
-display: "API Backend"
-description: "Headless API service — authentication, data model, public API, SDK, docs"
-recommended_modules:
-  - core
-  - execution
-phases:
-  - "01 — Scaffolding (framework, DB, migrations, CI)"
-  - "02 — Auth + API keys"
-  - "03 — Core resources + REST/GraphQL contract"
-  - "04 — Rate limiting + quotas"
-  - "05 — SDK + public docs"
-  - "06 — Observability + SLOs"
-next_steps: |
-  Seeded. Common follow-ups:
-    /rihal-council REST vs GraphQL vs both for this API?
-    /rihal-plan phase 01

package/rihal/templates/projects/mobile-app/PROJECT.md

@@ -1,37 +0,0 @@
-# {{project_name}} — Mobile App
-
-**Template:** mobile-app
-**Created:** {{date}}
-
-## What we're building
-A mobile app for {{target_user}} that solves {{core_problem}}. iOS + Android from day one.
-
-## Target user
-- **Who:** {{user_segment}}
-- **Context of use:** {{context}} (commute, at-desk, on-site, one-handed, etc.)
-- **Device assumptions:** {{device_assumptions}} (min OS, connectivity, battery tolerance)
-
-## Core value loop
-_(Describe the repeatable loop — 2-4 steps — that drives retention.)_
-
-1. {{step_1}}
-2. {{step_2}}
-3. {{step_3}}
-
-## Non-negotiables
-- Works offline for the core action (mobile users drop connectivity often)
-- Respects device permissions — no surprise background GPS, no over-asking
-- Respect platform conventions (iOS HIG, Material 3) before bespoke UX
-
-## Explicitly out of scope
-- Web app in v1
-- Tablet-optimized UI (phone-first)
-- Apple Watch / Wear OS
-
-## Key risks
-- **App Store review:** a single rejection can delay launch by 1-2 weeks; plan for it
-- **Performance on low-end Android:** test on a real <$200 device early
-- **Push opt-in rate:** <30% is common; design core loop to work without push
-
-## Evolution
-_(Updated after each phase completion by `/rihal-execute`.)_

package/rihal/templates/projects/mobile-app/template.yaml

@@ -1,17 +0,0 @@
-name: mobile-app
-display: "Mobile App"
-description: "iOS + Android app — onboarding, core feature, offline, push, store submission"
-recommended_modules:
-  - core
-  - execution
-phases:
-  - "01 — Scaffolding (framework, navigation, CI, TestFlight/Internal testing)"
-  - "02 — Auth + onboarding"
-  - "03 — Core feature"
-  - "04 — Offline + sync"
-  - "05 — Push notifications + deep links"
-  - "06 — Store submission + launch"
-next_steps: |
-  Seeded. Common follow-ups:
-    /rihal-council native (Swift/Kotlin) vs React Native vs Flutter for this app?
-    /rihal-plan phase 01

package/rihal/templates/projects/saas-b2b/PROJECT.md

@@ -1,40 +0,0 @@
-# {{project_name}} — Multi-tenant B2B SaaS
-
-**Template:** saas-b2b
-**Created:** {{date}}
-
-## What we're building
-_(One-sentence description — edit me.)_
-
-A multi-tenant B2B SaaS for {{target_customer}} that solves {{core_problem}}. Paying customers are organizations, not individuals.
-
-## Target customer
-- **Segment:** {{segment}} (e.g. mid-market ops teams, compliance-heavy industries)
-- **Size:** {{company_size}}
-- **Buying trigger:** {{trigger}}
-
-## Why now
-_(Market timing, regulatory shift, technology enabler, etc.)_
-
-## Monetization
-- **Model:** Subscription (per-seat / per-org / usage-based — pick one)
-- **Target ACV:** {{acv}}
-- **Trial strategy:** {{trial_length}} with {{trial_gating}}
-
-## Non-negotiables
-- Data isolation between tenants (hard requirement, not best-effort)
-- Audit log for every mutating action (for SOC2/ISO compliance paths)
-- SSO support by launch (SAML or OIDC — most B2B buyers require this)
-
-## Explicitly out of scope
-- Consumer tier
-- Self-serve free plan beyond trial
-- Mobile apps in v1
-
-## Key risks
-- **Technical:** multi-tenancy bugs = data leak = company-ending event
-- **Business:** long B2B sales cycles may outlast runway
-- **Regulatory:** PII/data-residency constraints depending on target market
-
-## Evolution
-_(Updated after each phase completion by `/rihal-execute`.)_

package/rihal/templates/projects/saas-b2b/template.yaml

@@ -1,18 +0,0 @@
-name: saas-b2b
-display: "SaaS B2B"
-description: "Multi-tenant B2B SaaS — auth, orgs, billing, RBAC, admin console, audit log"
-recommended_modules:
-  - core
-  - execution
-  - discovery
-phases:
-  - "01 — Foundations (auth, DB, env)"
-  - "02 — Multi-tenancy + RBAC"
-  - "03 — Billing + subscription lifecycle"
-  - "04 — Admin console + audit log"
-  - "05 — Observability + incident response"
-  - "06 — Launch readiness (SLA, docs, support)"
-next_steps: |
-  Seeded. Common follow-ups:
-    /rihal-council what's the first customer segment we should focus on?
-    /rihal-plan phase 01

package/rihal/templates/settings-hooks.json

@@ -1,75 +0,0 @@
-{
-  "_comment": "pre-edit hook is currently advisory (logs warning, does not block). Full session-read tracking requires PostToolUse Read hook to write state file. Implemented in follow-up.",
-  "hooks": {
-    "PreToolUse": [
-      {
-        "matcher": "Edit|Write",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node .rihal/bin/rihal-hooks.cjs pre-edit"
-          },
-          {
-            "type": "command",
-            "command": "node .rihal/bin/rihal-hooks.cjs compact-nudge"
-          }
-        ]
-      },
-      {
-        "matcher": "SlashCommand",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node .rihal/bin/rihal-hooks.cjs pre-workflow"
-          }
-        ]
-      },
-      {
-        "matcher": "Bash",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node .rihal/bin/rihal-hooks.cjs bash-guard"
-          }
-        ]
-      }
-    ],
-    "PostToolUse": [
-      {
-        "matcher": "Bash",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node .rihal/bin/rihal-hooks.cjs post-commit"
-          }
-        ]
-      }
-    ],
-    "PreCompact": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node .rihal/bin/rihal-hooks.cjs pre-compact"
-          }
-        ]
-      }
-    ],
-    "Stop": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node .rihal/bin/rihal-hooks.cjs stop-verify"
-          },
-          {
-            "type": "command",
-            "command": "node .rihal/bin/rihal-hooks.cjs cost-track"
-          }
-        ]
-      }
-    ]
-  }
-}

package/rihal/templates/summary.md

@@ -1,77 +0,0 @@
-# SUMMARY.md Template
-
-Each plan or sprint task produces a SUMMARY.md when it completes. The summary is the unit of work's lasting record — what was done, why, what remains, what other work it affects.
-
-## Frontmatter
-
-```yaml
----
-phase: NN
-plan: NN.M             # if applicable
-sprint: N              # if applicable
-story_id: NN.M         # if dev-story produced this
-generated: <ISO date>
-status: complete | partial | blocked
-verified: false        # flips to true after /rihal:verify-work passes
----
-```
-
-## Sections
-
-### One-liner
-
-A single line describing what was accomplished. Goes into `/rihal:progress` recent-work bullets, council recaps, milestone summaries. Be specific:
-
-> ❌ "Added some dashboard improvements"
-> ✅ "Wired live engagement metrics to dashboard top-3 tweets card; updates every 30s via SSE"
-
-### Outcomes
-
-What changed as a result of this work, observable from outside:
-
-- ...
-
-### Files touched
-
-```
-src/dashboard/Card.tsx        new
-src/dashboard/index.tsx       modified — added engagement subscription
-src/lib/sse.ts                new — SSE client wrapper
-test/dashboard.test.ts        new — 4 tests
-```
-
-### Decisions
-
-Decisions made during execution that aren't already in `state.decisions[]`:
-
-- **<decision>**: chose A over B because <one-line reason>. Tradeoff: <what we gave up>.
-
-### Issues encountered
-
-Problems hit during execution and how they were resolved:
-
-- **<problem>**: <one-line description>. Resolved by <action>. Time spent: <approx>.
-
-If a problem was NOT resolved, it goes here AND becomes a follow-up filed below.
-
-### Follow-ups
-
-GH issues filed (or to file) for work that this story surfaced but didn't ship:
-
-- #N — <title>
-- (to file) — <description>
-
-### Verification
-
-How a verifier confirms this story is actually done:
-
-- Run `<command>`, expect `<output>`
-- Open `<UI element>`, click `<button>`, observe `<state change>`
-
-This block feeds into UAT.md when the phase completes.
-
-### Status
-
-- **complete** — all acceptance criteria green, follow-ups filed.
-- **partial** — some AC green, others deferred. Document which AC are open.
-- **blocked** — couldn't proceed. Owner of unblock + ETA.

package/rihal/templates/verification-report.md

@@ -1,83 +0,0 @@
-# Verification Report Template
-
-Used by `/rihal:verify-phase`. Goal-backward analysis of whether the phase actually delivered the goal stated in ROADMAP.md.
-
-## Frontmatter
-
-```yaml
----
-phase: NN
-phase_name: <slug>
-verifier: <agent / human>
-verified_at: <ISO date>
-verdict: pass | fail | partial
-goal_source: ROADMAP.md (commit-sha-at-phase-start)
----
-```
-
-## Sections
-
-### Phase goal (verbatim)
-
-> <paste the goal statement from ROADMAP.md exactly as written when this phase was planned>
-
-### Goal decomposition
-
-The goal as one sentence is too coarse to verify against. Decompose into checkable claims:
-
-1. **Claim 1**: <one observable thing the goal implies>
-2. **Claim 2**: ...
-3. **Claim N**: ...
-
-### Evidence per claim
-
-For each claim, list:
-
-- **Source of truth**: code path / file / endpoint / behavior
-- **Verification method**: command / test name / manual step
-- **Result**: ✅ / ❌ / ⚠️
-- **Notes**: anything surprising
-
-```
-| # | Claim | Method | Result | Notes |
-|---|-------|--------|:------:|-------|
-| 1 | ... | ... | ✅ | ... |
-```
-
-### Coverage gaps
-
-What the phase goal said but no evidence-trail covered. List explicitly:
-
-- **<claim>** has no implementation that can be pointed to. Either:
-  - The goal was aspirational and the phase didn't implement it (gap to file as follow-up)
-  - The implementation exists but no test or doc covers it (gap to file as test debt)
-
-### Side-effect audit
-
-What the phase changed BEYOND the goal. Often these are silent:
-
-- New dependencies added
-- Schema changes
-- API contract changes
-- File-tree changes (new dirs, deleted files)
-
-Each side effect should be intentional and documented.
-
-### Verdict reasoning
-
-One paragraph explaining why the verdict (pass / fail / partial) was chosen. Include any judgment calls.
-
-### Follow-ups
-
-Issues filed (or to file) for gaps surfaced during verification:
-
-- #N — <title>
-- (to file) — <description>
-
-## Sign-off
-
-```
-Verifier: <name or agent id>
-Date: <ISO>
-Verdict: <verdict from frontmatter>
-```