add copy related to the focus on features, not points

1. everything is related to features, fk points, and assigning arbitrary points to incomplete deliverables to win second place trophies
2. its a paradigm shift on changing the metric from points delivered, to features consumed by users and impact being measured by product

• keep the focus on
  • features
  • managing the team winning races
  • drivers groove and keeping the team in their groove, whatever that may be for an individual driver
  • each race being a deliverable feature, dont break it down smaller than a deliverable feature
    • nothing should be merged to develop that isnt a fkn deliverable feature
  • building a race team that can win races

• we should understand our product in a such a way that everything is positioned from the perspective of a feature
• feature delivery estimation should be based on each individuals swimlane, rooted in historical data and not arbitrary point estimation
  • status quo: points / duration -> trend line
  • racexp:
    • slow lane: total features delivered / duration -> trend line
    • groove: total features delivered / duration -> trend line
    • fast lane: total features delivered / duration -> trend line
  • the delivery expectations for slow lane, groove, and fast lane will differ for each driver based on there own capabilities
    • e.g. the difficulty and speed for my javascript GROOVE is far different than it is for bujilding a webapp in binary

• this pattern requires more thought because the complexity of product mgmt increases but thats just the second law of thermo dynamics
  • the benefits outweigh the cost of the learning curve
  • the focus changes
    • from:
      • managing points in a sprint
      • treating point delivery as a proxy for feature delivery
    • to:
      • understanding feature delivery deadilnes
      • assigning features ( races ) to drivers (developers) who historically can meet those deadlines
      • managing drivers swimlanes

https://stackshare.io/posts/top-developer-tools-2022

• ci
• cd
• docker registry setup (its costing us $7 a month)
• aws locked down
  • automated billing & forecast reports and alerts
• authnz on test.nirv.ai
• completely immutable infrastructure, from dev to prod
• all dependencies are at the latest version
• all docs have been moved into docs repo
• docs are completely copypasta on debian
• docs: architectural decision records and diagrams are updated to match status quo
  • none of the diagrams look like a brainstorming sessions or labeled WIP
• everything on the RaceXP in Practice board is completed
• all non private written notes are somewhere in git
• update airgapped backup automation
• test.nirv.ai should not be accessible without some form of authn

C

T

A

• https://resources.github.com/security/tools/ghas-trial/

• see nim-lang/Nim#21332

• see nim-lang/Nim#21357

• see nim-lang/Nim#21339

in many places we reference something as being done, which isnt realistic

• @see community/community#8518

refactor is like a word from the 1800s, it will never sound good in a public conversation

we need something like upgrade or enhance

a first principle from the nim style guide

Good code usually happens after several rewrites: 
on the first pass, the focus is on the problem, not the code - 
when the problem is well understood, the code can be rewritten