EA-2136 sync architecture instruction files from org baseline

[bwell-dev]

Architecture Instruction File Sync

This PR updates the organization-wide AI agent instruction baseline files from icanbwell/.github.

Changes

• AGENTS.md: Organization-wide baseline (401 lines) codifying b.well architecture standards
• CLAUDE.md: Symlink to AGENTS.md for Claude Code compatibility
• copilot-instructions.md: Lightweight version for GitHub Copilot
• policies/approved-tech.yaml: Technology approval list
• .github/workflows: PR architecture review and commit message validation
• CODEOWNERS: EA ownership of instruction files

Source commit: e161131768903dde30cced1ebf0cc7188509ed58

Review Notes

Review and merge when ready. These are org-wide architecture instruction updates from EA team. These files are purely additive and don't modify existing code.

Related: EA-2130

[claude]

Warning

This review may be incomplete: some analysis steps could not run due to a temporary API capacity limit.

[claude]

🟡 The commit-message-checker regex uses the gm flags, so ^ matches the start of any line rather than the true start of the message — a commit/PR title with no JIRA key still passes the check as long as any later body line happens to start with an approved token (e.g. HP-123 ... or even the word Merge). This weakens the CI gate described by the error message ("Commit message must begin with a JIRA Issue Key"); drop the m flag (or anchor to the start of the string) so ^ only matches the message's true beginning.

Extended reasoning...

The bug: .github/workflows/check-commit-message.yml runs gsactions/commit-message-checker@v2 with pattern: '^(Bump|Merge|Revert|Reapply|build\(deps(-dev)?\): bump|([A-Z]+-[0-9]+))\s+.+' and flags: 'gm'. The action's source does new RegExp(pattern, flags).test(message) against the full commit/PR message as a single multi-line string (subject + body concatenated). Because flags includes m (multiline), ^ matches the start of every line in that string, not just the true start of the message.

Code path: For pull_request events, the action builds message = title + '\\n\\n' + body; for push events it checks each commit's full subject+body. Either way, the regex/flag combination is applied to a multi-line string where ^/m lets any line — not just the first — satisfy the pattern.

Why nothing else prevents it: there is no separate per-line vs whole-string mode selection happening elsewhere in the workflow; the input (which would drop the body) is not set, so the full multi-line message is checked, and the flag is applied directly to that entire message.

Impact: A commit or PR title that does not begin with a JIRA key (or one of the approved prefixes) can still pass the check, as long as some later line in the body/trailers starts with an approved token. This directly contradicts the check's own error message: "Commit message must begin with a JIRA Issue Key." In practice this is easy to trigger by accident — e.g. a body that quotes or references another commit/PR title, or a trailer, could contain a line starting with Merge or a JIRA-style token — silently defeating the intended enforcement.

Step-by-step proof:

1. Take pattern '^(Bump|Merge|Revert|Reapply|build\(deps(-dev)?\): bump|([A-Z]+-[0-9]+))\s+.+' and flags 'gm'.
2. Construct message 'fix a typo in readme\\n\\nHP-123 unrelated body text' — subject line has no JIRA key, but line 3 does.
3. new RegExp(pattern, 'gm').test(message) → true (verified directly with node). The check passes even though the subject/title lacks a JIRA key.
4. new RegExp(pattern, 'g').test(message) (dropping m) → false, correctly rejecting the message. This confirms the m flag is the root cause.

Fix: Remove the m flag from flags: 'gm' (leaving just 'g', or whatever flags the action requires without multiline semantics), or anchor the pattern to the whole string (e.g. using \\A/lack of multiline so ^ binds to index 0 only). This restores the intended semantics: the message must begin with an approved token.

This is a real correctness bug in a CI policy gate that was synced from the org baseline (icanbwell/.github) as part of this PR, so it is in scope for review here even though fixing it locally would diverge from that baseline. It only produces false negatives (weakens enforcement) — it doesn't cause any runtime failure, crash, or data loss, so it does not need to block merge.