Long-living project instructions/memory?

[jorgecolonconsulting]

Hi there. Is it possible to use project-specific instructions along with beads in a way that's long-lived? For instance, I currently create a PageIndex like yaml file with keyword tags, a small description, and a path to specific markdown files that expands on different project-specific topics. They could be about anything like guardrails on how to handle security, what specific technologies are using, code quality instructions, have to handle testing, etc. These pretty much exist and needed for the entire life of the project and should get updated over time when instructions change. The way I have it set up is to read instructions as needed depending on the intent of the task. For instance, if there's a change being done to the front end, it'll read the frontend markdown and not any other markdown that isn't related.

I'm trying to figure out how would that fit into the beads model where it seams like everything is tied to a "task" that eventually is completed. The only thing that came into mind was creating 1 "project instructions" top-level bead and then new tasks would link to that as a "related" issue. Not sure if that's the only approach.

[maphew]

I'd just put what you have above into a Readme at project root, reworded as instruction- or reference-like. Most agents seem to pick up Readme reliably on their own.

[jordanhubbard]

This gets trickier when you are asking for "checklist items" that you want all work to be done with, e.g. "you have just implemented feature X! Now"

1. Update the documentation to ensure feature X is properly described if user-facing
2. Make sure feature X has adequate test coverage
3. Make sure these new tests pass the CICD pipeline checks
4. If sample code or snippets are provided and this is relevant to feature X, add additional snippets or sample code
5. Update all build rules as appropriate to build feature X for both dev and prod

Yada yada yada. I have found that putting these instructions in AGENTS.md or .cursor rules or whatever also does not tend to apply them frequently enough - I can already see my favorite coding agents attempting (sometimes desperately) to reduce their burgeoning context sizes and K/V cache demands by only cherry picking out really strongly worded rules and ignoring the rest.

I think the idea of "standing beads" or "beads with affinity" that are not consumed but merely added to beads as sub-tasks once created has some merit, @steveyegge

[mrsimpson]

In my workflow organization tool (shameless plug: Responsible Vibe MCP), I'm using a trunk based development approach (feature branches). Each feature branch creates it own process memory (depending on the workflow used, bugfix, feature, ...).
In addition to the process memory, workflows may utilize long term project memory where requirements, architecture or design guidelines are recorded.

As per my experience, tasks are crucial, but phase specific instructions and recorded key decisions (across tasks) are equally important. Therefore, I didn't convert all my logic into beads forumlae and mols, but integrated beads into the existing tooling.