Tag: Standards
51 pages
- 01.01Project intake and scopingTurn "can we build a thing that…" into a scoped piece of work with a clear yes/no.
- 01.02Definition of done"Done" means the same thing to everyone.
- 01.03Communication standardsThe right conversation in the right place, findable later.
- 02.01Approved stack and when to deviateFewer technologies, deeper knowledge, easier handoffs.
- 02.02Project templates and starter reposEvery new tool starts from a known-good skeleton with CI, lint, auth, and deploy already wired.
- 02.03Folder and code structure conventionsOpen any repo and know where things are.
- 02.04Environment variables and config managementConfig is explicit, per environment, and never committed.
- 02.05Third-party services we useKnow what we depend on, who pays, and who holds the keys.
- 02.06Architecture decision logIndex of accepted ADRs (see 01.06 for the process).
- 03.01Account setup and multi-account handlingCommits land under the right identity, and personal/work accounts don't collide on Windows.
- 03.02Repo creation standardsEvery repo is discoverable, protected, and starts from a template.
- 03.03Branching strategyShort-lived branches, always-deployable main.
- 04.01TypeScript / JavaScript styleCode that any teammate (or Claude Code) can read and extend without asking.
- 04.02Python styleConsistent Python across data scripts and Rhino tools, which run in different interpreters.
- 04.03C# style (Revit / Rhino plugins)Plugins that survive Revit and Rhino version upgrades.
- 04.04Linting, formatting, and pre-commit hooksMachines enforce style so reviewers don't have to.
- 04.05Testing standardsEnough tests to change code with confidence, not so many that they slow us down.
- 05.01Approved AI tools and accountsEveryone has the right tool, on the right plan, under the right account.
- 05.02Claude Code standardsConsistent, safe, effective use of Claude Code across all repos.
- 05.03Cursor standardsCursor and Claude Code overlap; use each for what it's best at.
- 05.04Token usage optimizationFaster answers, lower cost, less drift — regardless of plan.
- 05.05Prompting patterns and reusable promptsPrompts that work, written down once.
- 05.06MCP servers we runAI tools can act on our systems through a known, controlled set of connectors.
- 06.01Environments: local, preview, productionThree environments, clear rules for what runs where.
- 06.02Vercel deployment procedureDeploys are automatic, boring, and reversible.
- 06.03Domains and DNSSubdomains on [TEAM: primary domain] managed in one place.
- 06.04CI/CD checks and required passesNothing reaches main without passing the same checks, every time.
- 07.01Secrets managementSecrets live in exactly one place and can be rotated in minutes.
- 07.02Access control and offboardingPeople have the access they need, and no more, and it disappears when they leave.
- 09.04Data schema registryShared datasets have one canonical shape so tools interoperate.
- 07.03Password manager and MFANo reused passwords, no accounts without a second factor.
- 07.04Client and project data handlingClient data stays where the client expects it.
- 07.05Dependency and vulnerability updatesStay patched without spending every Monday on version bumps.
- 08.01Supabase Auth setup standardEvery tool's login works the same way and is configured the same way.
- 08.02Roles and permissions modelOne simple role model reused across tools.
- 08.03Row Level Security patternsThe database enforces who can see and change what, regardless of how it's accessed.
- 08.04Session handling in Next.jsSessions are refreshed correctly on the server and never leak between users.
- 09.01Supabase project setup and configurationEvery Supabase project starts the same way and is findable.
- 09.02Schema design standards and namingSchemas that are obvious to read and cheap to change.
- 09.03Migrations workflowEvery schema change is a reviewed file in git, applied the same way everywhere.
- 09.05Backups and restore procedureLosing data is recoverable in under an hour.
- 10.01Rhino version, install, and license standardEveryone runs the same Rhino so tools behave the same.
- 10.02File and layer conventionsAny teammate or script can find geometry by layer, not by guessing.
- 10.03RhinoPython / RhinoScript standardsScripts that are readable, testable, and safe to run on a live model.
- 10.04Grasshopper standardsDefinitions others can open, read, and maintain.
- 10.05Rhino MCP: setup, use, and geometry generation workflowsUse Claude to generate and inspect geometry in Rhino safely and repeatably.
- 11.01Revit version and add-in environmentAdd-ins build and run on every Revit version the team supports.
- 11.02Plugin development standardsAdd-ins that are robust in real models and maintainable across years.
- 11.03Building, signing, and deploying add-insReleases are reproducible and installable without hand-copying DLLs.
- 11.04pyRevit / Dynamo standardsLightweight automation without a full add-in, kept as disciplined as compiled code.
- 11.05Model and family conventions relevant to toolsTools rely on models being structured predictably.