Initial commit

2026-05-25 05:47:28 +00:00
commit 4d6495ffda
97 changed files with 13403 additions and 0 deletions
@@ -0,0 +1,40 @@
+capability based use, not passing in the entire db
+- see wlaschin's presentations on capability based code
+
+label input as trusted or not, strings are no longer raw
+
+sanitization notes add trusted vs untrusted string input? ie save string source?
+
+are the security boundaries comprehensive enough? with 12 concerns I worry that is too many for one agent, I guess you can just keep doing security over and over again. do we cover enough concerns?
+add sanitization to strings
+mention seams from legacy code book
+make sure tests are property tests
+tdd for domain objects as well
+
+sub-agent / orchestration documentation ideas:
+- add shared orchestrator policy for scope control, restart criteria, and limits on agent freedom
+- add a formal failure taxonomy for agent runs, including drift, tool misuse, silent failure, and recovery notes
+- add evaluation thresholds and acceptance-check guidance for agent-produced work
+- add model-routing and cost rules for choosing cheaper vs stronger models
+- add escalation and recovery policies for when an agent should stop, hand off, or request a fresh context
+- add guidance for refactors: preserve backwards compatibility only with an explicit reason, otherwise prefer the direct change
+- add implementation guidance for future sub-agent benchmarks using real TypeScript tests as verification
+- add lightweight evidence-capture guidance so agent runs can be reviewed later without heavy documentation overhead
+
+
+# bounded seam identification tool:
+ it feels like you could have a tool that automatically identifies seams (ie seams are pretty obvious in this architecture right? they are layers in this template?) so you could have a tool that automatically traverses the changes so you can see what parts frequently need coordinated edits across seams? ie you could have this run every pr and then once there are places that get enough of a score you could start a refactor flow? or if there are pieces within a seam that always change independently then maybe they should be 2 bounded seams?
+And yes, your coordinated-change idea is strong. This repo’s explicit layers help, but seams are not just layers; they are places where behavior can vary independently. A tool could mine PRs/commits for:
+- files/functions frequently changed together
+- edits that cross module APIs
+- params/data passed through unchanged across many callers
+- repeated branching at the same boundary
+
+# need find bounded contexts step of feature
+need to find if there are new or existing bounded contexts. arrange repo by bounded context with shared primitives
+
+# do we have decompose feature into several workflows/tasks skill?
+define the difference between workflows and tasks
+
+# need process for refactoring
+ie I don't need to wait for the template to be done to use it I can just add the improvements later