ShurIQ Development Sprint 1: Welcome and Process Intro
Draft for the whole team: Kristine, Alex, Nicholas, Diana, Limore. Written in Jonny's voice for delivery as a Google Doc. Status: draft, pending Jonny's edit pass.
Welcome to our first proper development sprint. Until now, ShurIQ has been built through my solo process: one person, many terminal sessions, direct pushes. The reskin work we have been doing on reports was collaboration on output. This sprint is collaboration on the codebase itself, and that needs shared structure. This document is that structure.
The one rule under everything
We separate the work from the tools. Every activity in our development process (specifying a feature, sequencing a sprint, reviewing a change, tracking a blocker) is a method we own. GitHub and Jira are surfaces where those methods run. When you know the method, the tool is swappable; when you only know the tool, the tool owns the process. This is the same discipline we already apply across business development, fundraising, product design, and strategy: one grammar, one taxonomy, one ontology, expressed through whatever surface fits the audience.
Practically, that means we set up in two stages:
- GitHub foundations first (2026-07-17 through 2026-07-19). Repo, branches, issues, pull requests, reviews. No third-party layers. This takes a day or two and gives us the base every other tool plugs into.
- Jira mounted as a view, immediately after. Kristine gets admin and builds the sprint the way she runs sprints at Reffer: work by sprint, assignees, phases, dependencies. Jira reads from and writes to the same GitHub reality. Anyone who prefers working in GitHub Issues directly loses nothing; anyone who prefers Jira's framing loses nothing. Both views describe the same work.
Kristine, your intake form (separate doc) is how we make sure the setup matches the way you already manage development instead of asking you to relearn ours.
The three layers of the system
- The knowledge layer. My Obsidian vault holds the ontology, the report grammar, client intelligence, and the IP record. It stays private and it is never the dev repo.
- The code layer. A new private GitHub organization holds the ShurIQ monorepo: engines, modules, dashboards, the report renderer. One branch per feature, nineteen feature branches to start, following the pattern I set up for the simulation studio.
- The interfaces. Where code needs knowledge (rubrics, ontologies, report inputs), it reads through defined export formats and gated resource pointers, never by reaching into the vault. This boundary is what protects the IP while letting everyone build.
Part of sprint prep is an inventory: some code currently lives inside the vault and across a few project directories, and it moves into the monorepo as part of this setup.
Sprint 1 anchor: the terminal dashboards
From the 2026-07-16 sync, sprint 1 centers on the dashboard track:
- Consumer-facing terminal dashboard. Nicholas mocks up options from Kristine's write-ups; the anchor view is the brand score and its delta per portfolio brand.
- System admin dashboard. Internal views across the system, including report correction and feedback.
- Working wireframe dashboard. I deliver a live wireframe as the current plane we fly while the real one is built, so Kristine can test features the way she tests reports in the report studio.
Roles for this sprint:
| Person | Role |
|---|---|
| Kristine | Sprint lead: directives, scope, priorities, acceptance |
| Alex | Design: wireframe refinement, design language, renderer integration |
| Nicholas | Front-end build-out and integration, dashboard mockups |
| Jonny | Architecture, backend, endpoints, pull-request review and merge |
| Diana | Intake and pacing: the generic project intake form, review gates |
| Limore | Direction and client priority calls |
What every feature carries
Every feature branch gets an issue that states, before work starts:
- Scope: what is in, what is out.
- Intended outcome: what is true when it ships.
- Intended user: who it serves (terminal customer, enterprise client, internal team).
- Value to the system: what it adds to the underlying IP on its own, and what it unlocks in combination with other features.
This is the schema that lets sprint work stay legible to the business: the same fields drive product decisions, fundraising narrative, and pricing. A feature without these fields does not enter a sprint.
Working agreements
- One branch per feature. Work happens on the branch, lands by pull request, and I review and merge.
- The issue is the source of truth for a feature's state. Jira mirrors it; Slack references it; neither replaces it.
- Weekly sync remains the cadence checkpoint. The dashboards and the knowledge graph carry state between syncs so nobody has to interrupt anyone to find out what is happening.
- Requests enter through Diana's intake path, get paced and prioritized, and become issues. No side-channel work requests.
First actions
| Person | First action |
|---|---|
| Kristine | Fill the Jira intake doc; then build the preview sprint once Jira is up |
| Alex | Confirm GitHub handle; finish reskin handoff into the renderer branch |
| Nicholas | Confirm GitHub handle; start consumer dashboard mockups; review the three Figma architecture pages |
| Diana | Nicholas's weareshur email and access migration; block the review-gate session |
| Jonny | Stand up the org, monorepo, and 19 feature branches; then Jira with Kristine as admin |
| Limore | Send the Hasbro and RealPlay references |
Open decisions
- Organization name. The product name stays unnamed publicly per our standing rule, and GitHub org slugs are publicly discoverable even when every repo is private. Recommendation: a neutral slug for the org, product naming only inside private repos.
- Jira site. Not created yet as of 2026-07-17. It gets created after the GitHub foundation stands, per the sequence above.
- Repo inventory. Which code paths move from the vault and project directories into the monorepo, and in what order. This is the first item of the framework mapping sessions.