Development setup: the honest state on 2026-08-01
This document states what the engineering setup actually is right now, so an agent writing about it does not describe planned things as running things. It covers GitHub, Jira, the monorepo, the gates, the delivery grammar, the feature register, the order of work, and the roles.
Read it as the correction to any earlier description. Verified against the vault and against the live GitHub API on 2026-08-01. Style guide: Google developer documentation style.
The one-paragraph version
A GitHub organization exists and holds zero repositories. Jira does not exist at all. The monorepo is a written specification with two seed folders staged on disk. One gate script is written and its selftest passes, and it is not in any repository or any continuous integration system, because no repository and no continuous integration system exist. Sprint 1 is in specification, not execution. Everything downstream waits on one decision that belongs to one person.
GitHub
The organization is real. Queried live on 2026-08-01 with gh api orgs/shuriq-lab.
| Property | Value |
|---|---|
| Slug | shuriq-lab at https://github.com/shuriq-lab |
| Created | 2026-07-28T17:56:18Z |
| Plan | Team |
| Seats | 5 purchased, 3 filled |
| Repositories | 0 public, 0 private |
| Two-factor authentication | Required |
| Member repository creation | Disabled. Owners only |
| Base repository permission | Read |
Membership, from gh api orgs/shuriq-lab/members:
| Login | Person | Role |
|---|---|---|
jonnydubowsky |
Jonny Dubowsky | Owner, and the only admin |
AsianPelican |
Alex Ishida | Member |
nac70x7 |
Nicholas Crabill | Member |
Pending invitations: none. gh api orgs/shuriq-lab/invitations returns an empty
list, so the Alex and Nicholas invitations recorded as pending on 2026-07-28 have
since been accepted.
One team exists, core, privacy secret, with one member (jonnydubowsky) and zero
repositories attached.
One constraint discovered during setup: GitHub has no private-organization setting.
The organization profile page is always publicly visible. The stealth rule is
satisfied because discovery reveals a name and nothing about the framework, and the
2026-07-21 relaxation permits the shuriq-lab slug specifically.
The blocking fact
The organization contains zero repositories, and no repository name has been
chosen. The only candidate on record is platform, recorded as a recommendation on
2026-07-28. The slug decision is Jonny's alone.
This blocks the monorepo scaffold, the first pull request, continuous integration, the gates entering continuous integration, the registries becoming files under review, the route declarations, and the Jira project that would render issues from the repository. Every item in the order of work after step one is blocked on step one.
Jira
Jira does not exist. There is no Atlassian site. There is no project key. There are no epic identifiers in any tracker. There is no board, no sprint object, no backlog, and no ticket. Nothing has ever been created. An agent reading this must not describe Jira as running, connected, or partially configured, because none of those is true.
What exists is a written design, at
projects/shur/dev-sprint-1/sprint-plan-2026-07-27.md section 3. The rest of this
section describes that design. Everything in it is planned.
Planned: the system-of-record rule
GitHub is the system of record for the delivery work. Jira renders views of it. Where the two disagree, GitHub wins and the sync gets fixed. This rule exists to settle disputes before they happen, and it is the reason the repository has to exist before the tracker does.
Planned: issue types
| Type | Would map to | Note |
|---|---|---|
| Epic | E-01 through E-12 from the feature register, plus one Registries epic | Channels would render as Jira components |
| Story | S-01 through S-20 and successors | Route line first, then the prose user story. One story format, not two |
| Task | Registry seeding, gate scripts, migrations | Work that has no reader |
| Decision | One ticket per open decision | So a "blocked by" link has a real target instead of a memory |
The open decisions that would each become a Decision ticket are D-2 through D-7 and P-1 through P-6 plus P-8. D-8 and P-7 were closed on 2026-07-28. D-9 through D-12 are recorded as closed.
Planned: workflow states
Six states, mapped onto the seven stages of the feature development process guide.
| State | Process stage | Transition |
|---|---|---|
| Intake | 1. Design concept | Manual |
| Pool | 2 and 3. Spec written, awaiting adjudication | Manual, Jonny's verdict recorded on the ticket |
| Ready | Approved for the sprint, definition of ready met | Manual |
| In Progress | 5. Prototype and build | Manual on day one. Later, first commit on the branch |
| In Review | 6. Review | Manual on day one. Later, pull request opened |
| Done | 7. Production | Manual on day one. Later, merge closes it |
Deploy stays a separate human decision permanently. It is never a workflow transition.
Planned: the definition of ready
A four-field specification, taken verbatim from the process guide.
- The outcome.
- The reason.
- Local exceptions.
- How we will know it is right, expressed as three to six checks with at least one negative check.
Plus any open question addressed to a named person. A story missing any field is not ready. This goes into the Jira description template so the standard is the default rather than a review catch.
Planned: manual first
On day one every transition is manual, and the Jira-to-GitHub link is a URL pasted both ways by hand. None of the arrows is automatic.
Automation would arrive in this order and stop there:
- A GitHub issue auto-created from an approved story.
- In Progress and In Review transitions from branch and pull request events.
- Done on merge.
No transition automation ships before the manual version has run for at least one full sprint. Feeling the manual version is how we find out which steps matter.
Planned: estimation is undecided
There are no story points anywhere in the vault, in any register row, or in any specification. No estimation scheme has been chosen. Do not write one into a description of this system.
Two habits carried as process
Answers land on the ticket, never in Slack. "Blocked by" links are load-bearing, and every gated story carries one.
The planned monorepo
The layout is a specification. No repository holds it.
<slug>/ # name pending Jonny's decision
├── apps/
│ ├── report-studio/ # canonical copy is the outside repo at
│ │ # ~/Documents/projects/shuriq-report-studio/
│ ├── command-center/ # renders armed routes
│ └── atlas/ # static ops site, or stays a deploy artifact
├── modules/
│ ├── dashboard-design-studio/ # DEFERRED 2026-07-28. No build this sprint
│ ├── slack-agent/ # from projects/shur/slack-agent/
│ └── viz-studio/ # from ~/Documents/projects/viz-studio/
├── engines/
│ ├── kg/ # the shuriq_kg package
│ └── competitive-intel/ # SBPI semantic layer. Client data stays in the vault
├── interfaces/
│ └── okf/ # mirror, extractor, serving Worker, MCP server
├── registries/
│ ├── channels.yaml # CH-01 to CH-12
│ ├── forms.yaml # F-01 to F-20
│ ├── readers.yaml # R-01 only
│ └── routes/<client>/*.yaml # one file per route
├── intake/
│ └── <slug>/manifest.yaml # one deposit per intake
├── gates/
│ ├── route-gate.py
│ ├── template-gates/ # four checks, not written
│ └── grammar-gate.py # moves from projects/shur/report-grammar/
└── .github/
├── ISSUE_TEMPLATE/ # route-proposal.md, channel-registration.md, feature-spec.md
└── workflows/ # continuous integration wiring for the gates
Decided constraints on the repository, all of them planned:
- Private, default branch
main, branch protection onmain, pull request required, Jonny the sole merger. - No GitHub Projects boards.
- No hardcoded organization URLs, so a rename costs nothing.
- Secrets tracked by name in a
SECRETS.mdinventory. - Agent automation through a GitHub App rather than a machine user, because a bot account would consume one of the five paid seats.
- Issue labels from day one:
view:studio,view:command-center,layer:channel,layer:form.
Satellites stay behind interfaces for sprint 1: Aethelgard, totem-agent-framework, and myKG. Simulation Studio becomes a monorepo module. The report grammar canon, the voice specification, and the megaeval rationale stay in the vault permanently and never enter the repository.
The seed files, which do exist
projects/shur/dev-sprint-1/monorepo-seed/ is staged on disk so the repository is
populated the day it exists. It copies into the repository root as-is. Five files.
monorepo-seed/
├── README.md
├── gates/
│ └── route-gate.py
└── registries/
├── channels.yaml
├── forms.yaml
└── readers.yaml
Everything in the folder is a v0 draft for adjudication. Nothing is signed under Schema-is-Law.
gates/route-gate.py, 451 lines, deterministic, no model calls, exit 1 refuses a
merge. It was drafted 2026-07-27 and extended 2026-07-28 by a complexity audit. It
follows the grammar-gate.py precedent: measured facts only.
route-gate.py [--registries <dir>] [--routes <dir>] [--quiet]
route-gate.py --selftest
Defaults resolve relative to the repository root, which is the parent of the script's
directory: registries/ and registries/routes/. Zero route files is a pass, because
the gate guards what exists rather than requiring routes to exist. Exit codes: 0
clean, 1 violations, 2 usage or input error.
What it checks:
- Every channel, form, and reader a route references is registered.
- Every channel named in a channel's own
inputslist is registered, and the input graph is acyclic. - The action field is present and names a shipping type. Two of five types ship,
arm-ruleandopen-evidence. The three parked types are refused with a message naming what has to exist first. attenuatesstates a starting count and a resulting count. Two numbers, because non-emptiness passed any sentence somebody typed to get past the check.- An armed route's channels all reach a client destination. A route citing a channel
with status
unbuiltorlocal-onlymay beproposedand may not bearmed. - The
routeid matches the file's path. work_modeexists on the referenced reader record.action.type: arm-rulecarries anarms_ruletarget.statusis one ofproposed,armed,retired.evidenceis present.
The selftest builds fixtures in a temporary directory and asserts the verdicts, so no fixture file lives in the tree and no fake route can be mistaken for a real one. Run 2026-08-01:
$ python3 gates/route-gate.py --selftest
route-gate selftest: 13 cases, 0 failure(s)
Thirteen of thirteen, verified. Twelve route cases plus one registry-level case that a cycle in the channel input graph fails on its own.
registries/channels.yaml holds CH-01 to CH-12, each with an inputs list, all
currently empty. Three fields per channel are drafted and unsettled: address (null,
scheme undecided), freshness service level (marked PROPOSED, null meaning
event-driven), and visibility (null pending a team session, except CH-08's decided
constraint). Three statuses were corrected on 2026-07-28: CH-08 is live-one-client,
CH-10 is local-only, CH-12 is unbuilt. Before that pass the file read as twelve
live producers, which was wrong.
registries/forms.yaml holds F-01 to F-20 and nothing beyond. Eleven of the
twenty are built and rendering reports. F-12 to F-20 are marked deferred as build
candidates. Neither contested F-21-onward range was allocated, decided 2026-07-28. A
module carries its name until it is built, then takes the next free number at the
pull request that builds it.
registries/readers.yaml holds R-01 only, one real observed person, with two of
four work modes written. R-02 to R-04 were removed on 2026-07-28 rather than named:
three people nobody has met, carrying nine work modes with null scene, null question,
and null pain, for a client with one reader. A reader record returns when a named
person exists. The removed work-mode names and a naming conflict with the feature
register are preserved in the file's header comment so neither has to be
rediscovered.
Route declarations do not live in the seed folder. Zero real routes exist as
files. The first five come out of the kickoff session and enter through the
route-proposal issue template, gated by route-gate.py, never seeded by hand.
The gates
Three gate families, in the order they can exist.
| Gate | Where | State on 2026-08-01 |
|---|---|---|
grammar-gate.py |
projects/shur/report-grammar/grammar-gate.py |
Exists and is used by hand. Decided 2026-07-17 to enter continuous integration when continuous integration exists. Globs *.html only, so Markdown is ungated by construction. Found 2026-07-30 |
route-gate.py |
monorepo-seed/gates/route-gate.py |
Written, selftest 13 of 13. Blocked on the repository existing. Proposed as the repository's first pull request so the check exists before the first route does |
| Four template gates | Nowhere | Not written. Module fit, field availability, evidence reachability, attenuation stated. Blocked on decision P-8 and on the registries existing as files |
Until route-gate.py merges, the route check is a person reading the register, and
the process guide says so in those words.
Four style-coverage work items sit alongside the gates.
| Item | What | State |
|---|---|---|
| WI-10 | STYLE-REGISTRY.md, artifact type to style guide to gate |
Written 2026-07-30. Applied by hand |
| WI-11 | Extend grammar-gate.py to Markdown |
Not started. Needs a per-type rule set, because Google developer documentation style and the house voice canon fail on different things |
| WI-12 | style_guide: and reader: in the frontmatter schema |
Approved 2026-07-31 and applied to about 1,670 notes |
| WI-13 | A Shur technical documentation style guide | Parked. Google's is the interim answer |
The delivery grammar
The organizing model for the monorepo's registries/ tree.
Route = Channel x Form x Reader x Action, plus two gating fields, attenuates
and evidence.
- Channel. Where the intelligence comes from. Channel is named first.
- Form. How it renders. Form is named last.
- Reader. Who reads it, and in which work mode.
- Action. What the reader can do about it.
attenuates. What the route reduces, stated as two numbers so the reduction is measurable rather than asserted.evidence. Whether the figure opens its evidence. The default isrequired.
A channel may subscribe to other channels, which is how research, scoring, and negative-space mapping compose into one element. The input graph must be acyclic and the gate enforces that.
A route declares a standing query rather than a payload. A dashboard is what a set of route declarations composes into. The claim that ties this to delivery: a route declaration and a Jira user story are the same object in two vocabularies.
A route file is eight fields in YAML plus a pull request. The shape the gate enforces, marked v0 with adjudication pending:
route: dbm-global/thomas-monday-open
channels:
- id: CH-05
filter: "rank_change != 0 OR dimension_delta > 1.5"
form: F-07
variant: original # optional
reader: R-01
work_mode: monday-open
action:
type: arm-rule # arm-rule | open-evidence
arms_rule: dkr://rules/... # required when type is arm-rule
evidence: required # required | optional
attenuates: "21 movements reduce to 2"
status: proposed # proposed | armed | retired
Status of the grammar: draft and unsigned. Nothing in it is signed under Schema-is-Law. The vocabulary itself is a candidate, and the team settles the working language together. The plain-English version already in use is the sprint lead's four questions: what requires a decision, what changed, what is at risk and where is growth available, and what is being done.
Registries v0 hold 12 channels, 20 forms with 11 built, and 1 reader. Zero real route declarations exist as files. One route appears inline inside the team demonstration document as an illustration, and it is deliberately not a file.
The feature register
At projects/shur/dev-sprint-1/feature-register/, one Markdown note per row plus an
index and an Obsidian Base. Every feature and capability was read off the sprint
lead's actual screens, each with an honest statement of what produces it today.
Counted on 2026-08-01: 120 rows.
state: value |
Rows | Meaning |
|---|---|---|
works |
37 | Runs today with no person in the loop |
works-manual |
22 | Runs today with a person doing a step by hand |
not-built |
61 | Specified, nothing produces it |
priority: is null on all 120 rows. Nothing has been ranked. Ranking the
register is one of the named next decisions.
Row identifier prefixes and their counts: AX 20, CC 20, SB 17, AXV 17, FO 15, ED 10, SC 9, AXA 6, AG 4, OP 2.
The headline for the kickoff: the editorial report is largely built and the terminal around it is largely not.
One known repair: 12 of the 20 story route lines in the wireframe register cite a removed reader or a parked action type. The stories stand and the route lines do not.
The order of work
One list. Nothing reorders it.
- Jonny picks the repository slug. Waits on nothing. Recommendation on record:
platform. - Organization and repository created, the layout seeded from
monorepo-seed/, and~/.dotfiles/ai/skills/gets a git home. route-gate.pymerges as the first pull request.channels.yamlgoes live through story S-20.- The kickoff session runs, opening on the walked client chain. Five route declarations are produced.
- The sprint-1 cut builds, S-20 run health first.
- The Jira project mounts, once epics and the first stories exist to render.
- The registry adjudication pass completes the forms registry.
- Decision P-2 signs, and the pathway modules become buildable.
- Style coverage extends to Markdown in continuous integration alongside the other gates.
- The vertical intelligence block enters. Two questions gate it and both are Jonny's.
Steps 2 through 10 are all blocked on step 1.
Further items blocked and by what: template gates on P-8 and on the registries existing; stories S-13 and E-11 entirely on D-4, the work-item store, which has no replacement since TaskNotes was retired on 2026-07-25 and then reinstated as a provisional placeholder on 2026-07-28; the full application shell on D-2 and D-3, the design tokens and the type system, though a thin slice ships without them.
Roles
| Person | Role | Constraint |
|---|---|---|
| Kristine Hagedorn (KG) | Sprint lead: directives, scope, priorities, acceptance | Jira participant, never admin |
| Alex Ishida | Design: wireframes, design language, renderer integration | Owns form rendering |
| Nicholas Crabill | Front-end build and integration | Builds in the monorepo once it exists |
| Jonny Dubowsky | Architecture, backend, endpoints, pull request review and merge | Sole merger. Sole organization owner |
| Diana Horowitz | Intake and pacing, review gates | |
| Limore Shur | Direction and client priority calls | Reads internal documents as a principal, in plain English, with no translation step |
Jonny decides everything that enters the system. Everyone else proposes. There is no quality assurance function, and whether to add one is an open question.
Owner on a ticket means the person who accepts it and confirms acceptance on the running product.
Do not assume any of this exists
Every item below is specified in writing and has never been created, run, or deployed. An agent describing this system must present each of them as planned.
- The Jira site. No Atlassian instance. No URL.
- The Jira project. No project key, no board, no backlog, no sprint object.
- Jira epics and stories. E-01 to E-12 and S-01 to S-20 are identifiers in a Markdown register, not tickets in a tracker.
- Story points and any estimation scheme. Undecided. None exist anywhere.
- Jira-to-GitHub automation. Not built. The first version is a URL pasted by hand.
- The monorepo. No repository. The organization holds zero.
- The repository name. Not chosen.
platformis a recommendation, not a decision. - Every directory in the monorepo tree.
apps/,modules/,engines/,interfaces/,registries/,intake/,gates/,.github/are a layout in a plan document. - Continuous integration. No workflows, no Actions, no runners.
route-gate.pyin continuous integration. The script is written and its selftest passes. It is not in a repository.grammar-gate.pyin continuous integration. Same, and it covers HTML only.- The four template gates. Not written.
- Route declarations. Zero exist as files.
- The registries as repository files under review. They are seed drafts in a vault folder.
- A signed delivery grammar. Draft. Nothing signed under Schema-is-Law.
- Reader records R-02 to R-04. Removed on 2026-07-28 and not replaced.
- Three of the five action types.
review-and-assign,commission-research, andrun-simulationare parked with no destination, and the gate refuses them. - A work-item store decision. Decision D-4 is open.
- Feature priorities. All 120 rows carry
priority: null. - The GitHub App for agent automation. Decided in principle, not created.
SECRETS.md. Named as the inventory format, not written.- Issue templates and labels. Specified, not created.
- The dashboard design studio module. Deferred on 2026-07-28. No build this sprint.
What does exist, so the contrast is clear: the GitHub organization with three members and zero repositories, the five seed files including a passing gate script, the 120-row feature register, and the written plans that this document summarizes.