Development setup: the honest state on 2026-08-01

projects/dkr-agency/concept-space-2026-08-01-video-corpus/manus-pack/DEV-SETUP-STATE.md

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.

  1. The outcome.
  2. The reason.
  3. Local exceptions.
  4. 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:

  1. A GitHub issue auto-created from an approved story.
  2. In Progress and In Review transitions from branch and pull request events.
  3. 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:

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:

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.

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.

  1. Jonny picks the repository slug. Waits on nothing. Recommendation on record: platform.
  2. Organization and repository created, the layout seeded from monorepo-seed/, and ~/.dotfiles/ai/skills/ gets a git home.
  3. route-gate.py merges as the first pull request. channels.yaml goes live through story S-20.
  4. The kickoff session runs, opening on the walked client chain. Five route declarations are produced.
  5. The sprint-1 cut builds, S-20 run health first.
  6. The Jira project mounts, once epics and the first stories exist to render.
  7. The registry adjudication pass completes the forms registry.
  8. Decision P-2 signs, and the pathway modules become buildable.
  9. Style coverage extends to Markdown in continuous integration alongside the other gates.
  10. 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.

  1. The Jira site. No Atlassian instance. No URL.
  2. The Jira project. No project key, no board, no backlog, no sprint object.
  3. 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.
  4. Story points and any estimation scheme. Undecided. None exist anywhere.
  5. Jira-to-GitHub automation. Not built. The first version is a URL pasted by hand.
  6. The monorepo. No repository. The organization holds zero.
  7. The repository name. Not chosen. platform is a recommendation, not a decision.
  8. Every directory in the monorepo tree. apps/, modules/, engines/, interfaces/, registries/, intake/, gates/, .github/ are a layout in a plan document.
  9. Continuous integration. No workflows, no Actions, no runners.
  10. route-gate.py in continuous integration. The script is written and its selftest passes. It is not in a repository.
  11. grammar-gate.py in continuous integration. Same, and it covers HTML only.
  12. The four template gates. Not written.
  13. Route declarations. Zero exist as files.
  14. The registries as repository files under review. They are seed drafts in a vault folder.
  15. A signed delivery grammar. Draft. Nothing signed under Schema-is-Law.
  16. Reader records R-02 to R-04. Removed on 2026-07-28 and not replaced.
  17. Three of the five action types. review-and-assign, commission-research, and run-simulation are parked with no destination, and the gate refuses them.
  18. A work-item store decision. Decision D-4 is open.
  19. Feature priorities. All 120 rows carry priority: null.
  20. The GitHub App for agent automation. Decided in principle, not created.
  21. SECRETS.md. Named as the inventory format, not written.
  22. Issue templates and labels. Specified, not created.
  23. 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.