# Session 0058.0 — Transcript

> App: dev-claude-plugin
> Start: 2026-06-10T21-25 (PST)
> Type: brainstorming
> Claude-Session: 54e54d61-05bf-4b9a-b615-f655fbe88694
> Status: **PLACEHOLDER — claimed at session start; finalized at session end.**
>
> This file reserves session ID 0058 for dev-claude-plugin. The driver replaces this
> body with the full transcript and renames the file to its final
> SESSION-0058.0-TRANSCRIPT-2026-06-10T21-25--<end>.md form at session end.

## Launch prompt

```
These are my thoughts for the end-state of Phase 1 of our LLM-assisted SDL. Do a gap analysis with what we currently have in the eng handbook and claude dev plugin and then ask me clarifying questions to come up with what needs to be done to get from where we are now to where we need to go

Okay we're going to talk about our phase one software development life cycle requirements.
1. It starts with the wgl capture skill, which assigns a type to the getea issue that it creates.
2. We have a triage skill which looks at all untriaged getea issues in the project and makes a recommendation of rejecting or approving and what priority it should be. The main reason to reject would be that either something similar already exists or it conflicts significantly with existing functionality or it's just too far off the beaten path.
3. From there something can also be triage-approved but put in the parking lot, which is essentially: this is a good idea but compared to everything else that's open and on the backlog, it's just too much paperwork to consider it currently and so we'll reconsider it later. The parking lot is essentially all of the ideas that we're not going to get to in the next call, week, or two but that we want to review on occasion. There's no real process for reviewing parking lot items other than manually for now.
4. We should be able to run a skill to make recommendations for the top items to execute on based on priority and what's currently being executed on. If something is currently being executed on by another session and it's marked in progress, then if it's in a similar domain or code we might not want to execute on it. That's really replacing the /goal space next, where there is a skill that you can call and I don't have a name for it yet. That is essentially to look at all of the open items in Getea and choose the highest priority, highest value one that does not conflict with anything else that's currently being done.
5. From there we move on to the design stage where, if this is a feature that's been selected, we create a solution design, which is using the brainstorming skill. If it isn't we skip directly to execute, just like today, which is the planning and executing. We're going to move more towards a model where, once we've chosen a Getea issue that's being executed on, we actually create execution tickets. We should decide what those tickets are exactly but one would be if the design calls for non-trivial UI changes, which is defined as whatever we've put in the engineering handbook for whether or not Claude design needs to be used or not. We should create a ticket for the design. That is the human process of taking that ticket and giving it to Claude design so that Claude can design any kind of pages or UX. Once the design is done the design code itself will be. We actually need some kind of skill that will allow handing off a path to the zip file that we received from Claude design, as well as the Getea issue that represents the design that needs to be created. We update the ticket with that design so that during execution everybody has access to that design and needs to understand the relationship between that design ticket and any other execution tickets. We make sure that when we're executing on those tickets we understand how to find the design. From there we plan and execute each of the execution tickets, which could be slices. With each slice we verify with the dev end-to-end tests on localhost/docker and then it is deployed to PPE (pre-production), which is really the UAT environment. End-to-end tests are run at that point. A human manually checks PPE and plays around and validates the new functionality and then chooses to deploy to prod. We need to figure out how it is that the human deploys to production. It should be after dev, before PPE; everything should be merged in domain. We should always be deploying main onto both PPE and production. It might make sense to do a tag so that we know that what we deploy on the PPE is also what we deploy on production. We need to talk through that and when we deploy on production we have our blue-green, which will monitor and roll back if we see users encountering issues. Finally after deployment we have monitoring, where we're capturing operational telemetry, product telemetry, and traces. What we want is our final phase one and phase two will have actual agentic autonomous agents that will interact with this pipeline. For now we just want to make sure that a human can run it in a Claude Code environment using skills and that we can test it out a bunch of times before we start automating anything else.

```

## Plan

1. Survey current state: eng handbook (capture→issue→design→plan→code spine, §9 pipeline, §10 blue/green, monitoring) and dev plugin (skills, hooks, open tracker issues).
2. Map the operator's 9-stage Phase-1 SDL end-state against that current state → gap analysis.
3. Ask clarifying questions (incl. the anchoring-issue question — this topic is epic-scale and likely needs decomposition).
4. Converge on "what needs to be done" — likely a Solution Design and/or captured issues, per operator's steer.

## Decisions so far (Phase-1 SDL model)

1. **Execution tickets are real Gitea child issues at slice grain** — overturning Capture RFC §8.1's checklist-only model. Plan-step tasks still never enter the tracker. Feature body keeps an auto-generated checklist of links as a dashboard.
2. **Ticket spawn timing**: "Author Solution Design" task ticket at triage-approval (the actionable unit for a Feature, per #99); UI Design ticket (if spec §5.1 scores Design) + slice tickets at design graduation, with Gitea dependencies wired (UI slices blocked-by the UI Design ticket).
3. **`/goal next <feature#>` = deterministic query** over the feature's open children: next ready = dependencies green + not locked/in-progress. Blocked-on-designs is reported, sibling non-UI slices may proceed.
4. **Pipeline story**: slices merge to main and deploy to PPE continuously (autonomous, incl. in yolo); each PPE deploy stamps a tag; the human validates PPE at their own cadence and promotes the *validated tag* to prod — the single human gate. Fix-forward on main (prod never exposed to unvalidated refs). "Done" (merged+PPE-green, ticket closes) is distinct from "shipped" (tag in prod).
5. **Session output**: a list of capture prompts for missing tickets + change prompts for existing tickets; then (on operator's go) an Epic ticket with all of these as children, dependency-ordered. Includes a mandated capture: attempting solution design or execution on a ticket with incomplete prerequisites must FAIL deterministically.

## Epic assembly (executed)

- Verified the operator-filed tickets: engineering#43 (handbook rollout story), engineering#44 (E2E machinery), flotilla-core#13 (release/promote) existed; the five plugin-side features were unfiled drafts in the content repo `issues/` — filed them as #109 (wgl-triage), #110 (approval-time SD-ticket spawn), #111 (graduation-time slice/UI-Designs spawn), #112 (open-blocker eligibility gate), #113 (promote gesture). The blue/green watcher had NO ticket anywhere (handbook's "building session #42" reference is stale — engineering#42 is an unrelated closed backup slice); filed it as flotilla-core#15.
- Created the Phase-1 epic: **engineering#45** (`type/epic`, P1) with the full stage-grouped children checklist across all three trackers.
- Wired 19 blocked-by edges (2 in the cross-repo verification earlier + 17 now), incl. cross-repo: plugin#113 ← flotilla-core#13 ← engineering#43; flotilla-core#15 ← engineering#25. Verified `ALLOW_CROSS_REPOSITORY_DEPENDENCIES` is enabled on git.wiggleverse.org (Gitea 1.26.2) empirically.
- API pitfall recorded: dependencies POST body is `{index, owner, repo}` — `name` instead of `repo` yields a misleading 404 IsErrRepoNotExist.
- Content repo: stamped drafts committed + pushed to main (b59a0be).

## Deferred decisions

_Autonomous-mode low-confidence calls the driver made and would have
liked operator input on. Appended as the session runs; surfaced at
finalize. Empty if none._
