What do you want to build?
What we've built so far here in hoopstat-haus is good, but I want to build a repeatable platform for similar apps using the lessons I've learned, and dogfood the initial v1 release of the "real" hoopstat.haus project using said templates to prove their viability.
Goal: Multiple template repos set up to enable rapid develop- and deployment of projects similar to what I've built so far here. The template repos I had in mind and their purposes follow. For each *-blueprint repo, it should be able to spin up/deploy a * project in ~5-10 minutes with minimal manual setup. We're making a set of cookie-cutter templates to create software factories.
blueprint-repo-blueprints: the "grandparent" of all the other repos, contains development philosophy, basic app/lib/doc/meta folder structure, general AI instructions, common-ish READMEs and other documentation. Language agnostic. Needs to exist and be completed first, so the other blueprint repos can be cut from it.static-js-app-blueprint: I've already taken a stab at this, but I want to do it better using the above template-template repo. Does not enforce vanilla js vs framework, but is intended to build to a single static artifact. By default, it should be platform-agnostic and deploy to GH pages. But it should also be easy to opt-in and set some config values to start an s3 cp ... and cloudfround invalidate workflow for easy AWS integration. In either case, "infrastructure" is beyond the scope of this template repo. Accessibility concerns are in scope though.python-project-blueprint: cut from the blueprint-blueprint as well, but set up targeting python development specifically. Multiple apps and libs using the monorepo structure we have here, and platform agnostic by default. The example app should show (but not actually impl, comment out the key bits) PyPI as the default publish path, with minimal Docker images also being built in CI by default (but no push destination for those, just the GH action artifact)python-aws-data-blueprint: an extension of python-project-blueprint, containing AWS integration: lambda images, ECR usage, terraform, s3; the medallion architecture idea may fit here we'll see. The example definitely doesn't have to actually work here, it won't have credentials. But it should exist, just with placeholder values.
Once that's all done, I want to cut the "final" hoopstat.haus repos: hoopstat-data and hoopstat-app, using the mature python-aws-data-blueprint and static-js-app-blueprint templates to initialize them.
I've come up with a rough plan; I want you to expand, iterate, and question it until we're both confident it's bullletproof. The epics I had in mind follow, feel free to push back on whether these all need to exist (or add another if I've missed something).
- file-by-file investigation: which existing hoopstat-haus content belongs in which repo, long term? My repomix config can probably live in all repos, where all of /frontend-app belongs in
static-js-app-blueprint and/or hoopstat-app. This is your task to start, generate a markdown document that maps folders (or files where appropriate) to their final location, with notes as needed.
- full implementation and rollout of blueprint repos: create, implement, aggressively review, and tidy up again each of these in sequence. For each of these, please generate an epic with issues as described in impl note below.
blueprint-repo-blueprintsstatic-js-app-blueprintpython-project-blueprintpython-aws-data-blueprint
- Initial cut and base impl of
hoopstat-data and hoopstat-app. Generate epic writeups for both of these as well, but be congizant of our choice to copy vs rewrite each part of the existing project.
- Archive/teardown existing repo: tear down infra, remove tokens, stop bronze cronjob. We need an epic plan here too.
- Integration and deployment: hoopstat.haus v1. This is the most important epic to plan.
- new AWS tokens working for both repos
- hoopstat-data generating the needed infra
- hoopstat-app deploying its artifact to s3 with a different role
- human-run route53 cleanup/changes
- bronze cronjob started again
- MCP app deploying to PyPI
Acceptance Criteria
None really; this is a planning request. Write the overall executive summary in the PR description, and then for each suggested epic above (+/- whatever you think necessary) follow the impl notes below. The issues themselves will be created manually on the relevant repos.
Take your time on this, and iterate a few times. It's far more important to get this right than to do it quickly.
Implementation Notes (Optional)
This is an epic-level ticket; I'm not actually going to merge anything you create.
The deliverable output I want from you is a series of markdown files in a new folder under meta/plans.
Each of these files is to be a small, easily verifiable chunk of work that I can then use to create a new github issue. Include all the fields used in .github/ISSUE_TEMPLATE/feature-request.yml (AC, impl notes, etc) for each ticket.
Create an executive summary document for this epic, as well as the above work "chunks" as a sequenced series of tickets.
Review meta/adr before starting for any relevant ADRs, and consider proposing a new one if you feel another decision needs to be made and documented.
What do you want to build?
What we've built so far here in hoopstat-haus is good, but I want to build a repeatable platform for similar apps using the lessons I've learned, and dogfood the initial v1 release of the "real" hoopstat.haus project using said templates to prove their viability.
Goal: Multiple template repos set up to enable rapid develop- and deployment of projects similar to what I've built so far here. The template repos I had in mind and their purposes follow. For each
*-blueprint repo, it should be able to spin up/deploy a*project in ~5-10 minutes with minimal manual setup. We're making a set of cookie-cutter templates to create software factories.blueprint-repo-blueprints: the "grandparent" of all the other repos, contains development philosophy, basic app/lib/doc/meta folder structure, general AI instructions, common-ish READMEs and other documentation. Language agnostic. Needs to exist and be completed first, so the other blueprint repos can be cut from it.static-js-app-blueprint: I've already taken a stab at this, but I want to do it better using the above template-template repo. Does not enforce vanilla js vs framework, but is intended to build to a single static artifact. By default, it should be platform-agnostic and deploy to GH pages. But it should also be easy to opt-in and set some config values to start ans3 cp ...andcloudfround invalidateworkflow for easy AWS integration. In either case, "infrastructure" is beyond the scope of this template repo. Accessibility concerns are in scope though.python-project-blueprint: cut from the blueprint-blueprint as well, but set up targeting python development specifically. Multiple apps and libs using the monorepo structure we have here, and platform agnostic by default. The example app should show (but not actually impl, comment out the key bits) PyPI as the default publish path, with minimal Docker images also being built in CI by default (but no push destination for those, just the GH action artifact)python-aws-data-blueprint: an extension ofpython-project-blueprint, containing AWS integration: lambda images, ECR usage, terraform, s3; the medallion architecture idea may fit here we'll see. The example definitely doesn't have to actually work here, it won't have credentials. But it should exist, just with placeholder values.Once that's all done, I want to cut the "final" hoopstat.haus repos:
hoopstat-dataandhoopstat-app, using the maturepython-aws-data-blueprintandstatic-js-app-blueprinttemplates to initialize them.I've come up with a rough plan; I want you to expand, iterate, and question it until we're both confident it's bullletproof. The epics I had in mind follow, feel free to push back on whether these all need to exist (or add another if I've missed something).
static-js-app-blueprintand/orhoopstat-app. This is your task to start, generate a markdown document that maps folders (or files where appropriate) to their final location, with notes as needed.blueprint-repo-blueprintsstatic-js-app-blueprintpython-project-blueprintpython-aws-data-blueprinthoopstat-dataandhoopstat-app. Generate epic writeups for both of these as well, but be congizant of our choice to copy vs rewrite each part of the existing project.Acceptance Criteria
None really; this is a planning request. Write the overall executive summary in the PR description, and then for each suggested epic above (+/- whatever you think necessary) follow the impl notes below. The issues themselves will be created manually on the relevant repos.
Take your time on this, and iterate a few times. It's far more important to get this right than to do it quickly.
Implementation Notes (Optional)
This is an epic-level ticket; I'm not actually going to merge anything you create.
The deliverable output I want from you is a series of markdown files in a new folder under meta/plans.
Each of these files is to be a small, easily verifiable chunk of work that I can then use to create a new github issue. Include all the fields used in .github/ISSUE_TEMPLATE/feature-request.yml (AC, impl notes, etc) for each ticket.
Create an executive summary document for this epic, as well as the above work "chunks" as a sequenced series of tickets.
Review meta/adr before starting for any relevant ADRs, and consider proposing a new one if you feel another decision needs to be made and documented.