claim dev-claude-plugin session 0058 (placeholder) + sessions.json entry

2026-06-10 21:26:45 -07:00
parent 39e22ebba4
commit 266dd404df
2 changed files with 34 additions and 0 deletions
@@ -0,0 +1,31 @@
+# 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.
+
+```
+
+## 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._
@@ -169,5 +169,8 @@
  },
  "0057": {
    "title": ""
+  },
+  "0058": {
+    "title": ""
  }
 }