[Context] BTP/Foundry alignment initiative — conversation record

[dnovick]

Purpose

This issue captures the initiating conversation (August 2026) that launched the BTP/Foundry alignment initiative for berean-bible-bots. It serves as a durable reference for why these issues exist and what was decided.

Background

David Novick is becoming a partner in Baldwin Technology Partners (BTP), a small company run by Mark. BTP has several AI agent–driven projects:

• bedrock-chat / law-hipaa-deployment — a medical-legal app
• trellis-vault — Mark's personal admin assistant
• foundry — a set of standards, runbooks, and SDLC governance that all BTP projects follow

All BTP repos are cloned locally at ~/gitrepos/projects/btp/.

Goals of This Initiative

1. Foundry familiarization — David needs to learn foundry and assess what is directly applicable to berean-bible-bots vs. what is specific to BTP's enterprise fleet infrastructure.

2. Multica evaluation — Mark uses Linear; David uses GitHub Issues. Both want to evaluate Multica as a unified platform for agent orchestration and issue tracking. berean-bible-bots will be the test vehicle.

3. Foundry adoption — Align berean-bible-bots with foundry standards to improve consistency, quality, and documentation. Key pain points: exercise formatting inconsistency (answer row alignment, dropdown selects), missing project-level documentation (SRS, architecture doc, ADRs).

4. Better orchestration — Improve how Claude and additional agents collaborate on this project: parallel review agents, multi-LLM consultation for significant architectural decisions, test agents for generated exercises.

5. Reduced approval prompts — Define durable policies so routine actions (git commits, branch creation, lint runs, file writes within the project) don't require per-action approval.

6. Foundry as a reusable asset — As David and Mark work together, they want to improve foundry so it's applicable to any AI agent–driven project, not just BTP's fleet setup. This means separating fleet-specific standards (PKI, pod auth, VM provisioning, fleet filesystem layout) from universally applicable ones.

Related Issues

• See sibling issues tagged [BTP/Foundry], [Multica], [Quality], [Orchestration], and [Policies] created alongside this one.

Foundry Standards Read (August 2026)

The following foundry standards were reviewed as part of this initiative:

• ci-cd-standard.md — GitHub Flow, 10-step deploy-before-merge, DORA metrics
• clean-room-external-repo-security-review-standard.md — external repo security review
• cli-tooling-provisioning-standard.md — CLI agent provisioning (Claude Code, Codex, Gemini)
• configuration-classification-standard.md — Tier 1/2/3 config classification
• development-methodology.md — Python prototype → TypeScript production pattern
• documentation-standard.md — documentation as teaching, four audiences
• fleet-filesystem-layout-standard.md — fleet VM layout (likely not applicable to berean-bible-bots)
• fleet-pki-*.md — internal PKI (not applicable)
• pod-auth-standard.md — dev pod credential hardening (not applicable as solo project)
• issue-triage-standard.md — P1–P4 priority + Timing bucket vocabulary
• multi-llm-consultation-standard.md — multi-LLM design + implementation review
• project-document-ecosystem.md — minimum viable + complete document sets for a project

Key Decisions from the Conversation

• Multica will be evaluated using berean-bible-bots as the test vehicle before any decision to move Mark off Linear.
• GitHub Issues will remain the external-facing reporting channel during the evaluation; integration with Multica is a sub-problem.
• Foundry adoption on this project should focus first on the universally applicable standards (CI/CD, documentation, issue triage, multi-LLM review, session continuity) — not on fleet/pod/PKI infrastructure.
• The user wants Claude to make most routine decisions autonomously; the approval-prompt reduction work should produce durable policy files (analogous to CLAUDE.md entries or a policies.yml) rather than per-session overrides.