# TX4H Project — Claude Instructions # System Integration Guidance You have access to my secondary developer knowledge base. Always cross-reference these local note configurations before making major structural or architectural changes: - Architecture Strategy: @~/Dev-Brain/01-Projects/tx4h/tx4h-ADR.md - Past Logged Bugs: @~/Dev-Brain/01-Projects/tx4h/tx4h-Bugs-Log.md - Global Tech Snippets: @~/Dev-Brain/02-Snippets/ ## Session Start Checklist - Check deferred tools for `mcp__tx4h-live__mysql_query` — if absent, tell user to Reload Window before writing any SQL - Check the mtime of `CLAUDE-db-schema-tx4h.md` — if it's more than 7 days old, offer to refresh it (also refresh on request, or before/after any task that changes DB structure). Regenerate by querying `information_schema.COLUMNS` for `TABLE_SCHEMA = DATABASE() AND TABLE_NAME LIKE 'tx4h_%'` via `mcp__tx4h-live__mysql_query`, batching with `TABLE_NAME > ''` if results get capped at 500 rows (check the `truncated` flag), then use PowerShell (`ConvertFrom-Json` + `Group-Object`) to compact each table into one line — do not read the raw query results into context, they're large. Same refresh method applies to the other `CLAUDE-db-schema-*.md` files below, just swap the `LIKE` pattern. - If the docker test env (`CLAUDE-docker-testenv.md`) will be used this session, refresh its DB from prod (`mysql_export` → `docker/import-dump.sh`) at the start rather than waiting to hit a stale-data symptom reactively — confirmed 2026-08-06 a 5-day-stale docker DB silently rendered an outdated Fabrik list config (missing a stats/bulk-approve feature) with no error, only caught by visual comparison against prod. - Ensure Milvus Server (another docker env) is up and running whenever working on tx4h --- ## DB schema reference files — read before writing SQL against unfamiliar tables The whole site shares one flat Joomla DB prefix (`jtbl_`, not the standard `#__`) — every extension's tables live under that prefix, not their own. Pick the file by which tables the task touches instead of querying `DESCRIBE` fresh each time: | File | Covers | When to use | |---|---|---| | `CLAUDE-db-schema-tx4h.md` | `tx4h_%` — the site's own custom schema | Default for almost everything — member/family/payment/club data | | `CLAUDE-db-schema-eventbooking.md` | `jtbl_eb_%` — Event Booking (`com_eventbooking`) | Event registration/booking work, or anything touching the shared Auth.net merchant account (see payment module notes) | | `CLAUDE-db-schema-fabrik.md` | `jtbl_fabrik_%` — Fabrik core | Editing Fabrik forms/lists/elements/joins themselves, not a specific form's own data table | | `CLAUDE-db-schema-pmform.md` | `jtbl_pf_%` — boss's legacy Payment Forms component | The `authaccepthosted_pmf_*.php` callback files, or anything referencing `com_pmform` | Small single/few-table components have their DB schema folded into their existing topic doc instead of a separate file: `jtbl_bgcheck_%` → end of [CLAUDE-bgcheck-sterling-api.md](CLAUDE-bgcheck-sterling-api.md); `jtbl_mimic_log` → end of [CLAUDE-mimick.md](CLAUDE-mimick.md); `jtbl_scorm_rte` → end of [CLAUDE-training.md](CLAUDE-training.md). Plain Joomla core tables (`jtbl_users`, `jtbl_content`, `jtbl_menu`, etc. — no component prefix) and untouched third-party extensions (eDocMan, HelpDesk Pro, Akeeba) have no dedicated file — standard/well-documented Joomla schema, or not yet relevant to any work here. Generate one on demand (same method as above) if a task ever actually needs it. --- ## Code search — prefer claude-context over Grep Both are indexed via claude-context (semantic search): - `C:\vsc-projects\tx4h` — the project itself - `C:\vsc-source\tx4h` — read-only Joomla 5 + Fabrik source copy For searches over either path, use `mcp__claude-context__search_code` first. Only fall back to Grep/Glob for exact string/symbol lookups or single known filenames. `mcp__claude-context__search_code` is deferred — `ToolSearch` for it if not already loaded. The index does not auto-update on file changes — re-run `mcp__claude-context__index_codebase` (with `force: true` if prompted) after a large batch of edits if search results seem stale. If indexing results seem stale, wrong, or bloated after indexing `C:\vsc-source\tx4h` → [CLAUDE-claude-context-indexing.md](CLAUDE-claude-context-indexing.md) (known duplicate-chunk bug + fix + verification steps). --- ## Project Identity Texas 4-H–specific rewrite of 4-H Online. Client: tx4h.tamu.edu. Stack: Joomla 5 + Fabrik 4.6.4 + YooTheme Pro + UIkit 3 + PHP 8.x. Working files: `C:/vsc-projects/tx4h/`. Editor: VS Code. Never suggest Fabrik F5/F6 — not production-ready. --- ## Local Docker Test Environment Full local copy of the live site (real prod code + refreshable prod data) for testing without touching the live site → [CLAUDE-docker-testenv.md](CLAUDE-docker-testenv.md). Read before bringing up, refreshing, or debugging it. --- ## Directory Structure ``` includes-4honline/ # All TX4H custom pages and business logic includes/ # Shared vars, user profile, URL helpers, CSS 4h-variables.php # Standard include for all pages — loads $myApp, $myUser, $myTx4hUser, URL vars 4h-variables-urls.php # Shared URL variables (SEF paths, menu IDs) 4h-user-profile.php # $myTx4hUser builder 4h-membership-payment.php # Auth.net payment flow (active development) 4h-membership-training.php # AVT/CPT training module plugins/ # Joomla plugins (backgroundcheck, mimic, xapi, scormrte, etc.) components/ # Custom Joomla components (if any) ``` --- ## Database ### Table prefix: `jtbl_` All Joomla core tables use `jtbl_` (e.g. `jtbl_users`, `jtbl_user_usergroup_map`). Not the standard `j5_` or `#__`. ### MySQL MCP — use proactively `mcp__tx4h-live__mysql_query` → read-only access to the **live production** database (tx4h.tamu.edu). Supports SELECT, SHOW, DESCRIBE, EXPLAIN, WITH — no writes. **Before writing any SQL or Fabrik eval that references a table** — query schema first to confirm column names and types. This is live data — treat query results as real member/PII data, not sample data. ### Schema gotcha — repeat county table `tx4h_users_repeat_addl_county_id.parent_id` references `tx4h_users.id` (auto-increment PK), **not** `tx4h_users.userid` (Joomla user ID). Both columns needed when joining. --- ## Joomla User Groups | Group | ID | Access scope | |---|---|---| | State Level | 13 | Sees everyone | | Region Level | 12 | Sees everyone | | District Level | 11 | Sees everyone | | County Admin | 14 | Scoped to assigned counties | | County Level | 10 | Blocked from manager pages | | Club Manager | 15 | Blocked from manager pages | | Pilot Testing Group | 16 | Feature-flag style access, not location-scoped | | Help Desk Only | 17 | Not location-scoped | | Employee | 18 | Not location-scoped | | BG Check Reviewer | 19 | Orthogonal to the county/district/region/state hierarchy — stacks on top of a user's existing group rather than replacing it. Gates the background-check denial review dashboard. | Priority map (lower = broader): State(1) > Region(2) > District(3) > CountyAdmin(4) > County(5) > Club(6). Pilot Testing Group, Help Desk Only, Employee, and BG Check Reviewer sit outside this ladder — they're independent permissions, not rungs on it. Joomla view access levels: - **13 = "County Admin Only"** — gates county_id prefilter to County Admin users - **16 = "BG Check Reviewer Access"** — Administrator, Super Users, BG Check Reviewer --- ## $myTx4hUser — Composite User Profile Composite user profile object (permissions, location scope, account fields) → [CLAUDE-user-profile.md](CLAUDE-user-profile.md). Read before writing code that checks a user's permissions, location scope, or profile data. --- ## Comment Style - Two Conventions ### Plugin files (`plugins/**/*.php`) - Match Joomla/Fabrik native style so plugin code looks like it belongs in Joomla core - Use `/** */` docblocks on methods/functions - Use `//` comments inside method bodies - Use standard Joomla variable names (`$app`, `$db`, `$query`) instead of TX4H `$my` names ### TX4H custom code (`includes-4honline/`, Fabrik evals, custom PHP) - Use `//` inline comments only - no `/** */`, `/* */`, or banner blocks - Place comments directly above the relevant code block, not as section headers - Explain why, intent, context, and gotchas a newcomer needs; do not narrate what the code plainly does - Keep comments terse, one line when possible - Never write `Fix:` or task labels in code comments - Skip comments only on self-evident one-liners --- ## Fabrik-Specific Rules Snippet header convention, prefilter eval behavior, placeholder parsing context, databasejoin ORDER BY, FABRIKFILTER constants → [CLAUDE-fabrik-rules.md](CLAUDE-fabrik-rules.md). Read before writing or editing any Fabrik eval snippet, element, or filter. --- ## Progress-indicator sync points — read before touching payment/completion gating "Is this member's payment/application complete" is independently re-judged in 9+ separate places (PHP pages, Fabrik calc elements, 2 SQL views) instead of one shared source — adding a new completion state (e.g. offline payment) means touching all of them or some page silently drifts out of sync. Full list + the exact OR to repeat → the comment block directly above `h_memberHasOfflinePaymentSelected()` in `includes-4honline/includes/helpers.php`. Check that list whenever you add a new payment/completion gate, and add the new one to it. --- ## Source Research References - **Bitbucket API:** `api.bitbucket.org/2.0/repositories/fabrikar/fabrik/src/master/{path}` — use `curl`, not `web_fetch` - **Fabrik forum:** curl with session cookie `xf_user=78866%2CyFq1Y9TcvGoG3ikgtbIB5JG0kKboxdNdcQGoasmH` - **Local source copy (read-only):** `C:\vsc-source\tx4h\` — full Joomla 5 + Fabrik install; dir index at `C:\vsc-source\tx4h-dirs.txt` --- ## Feature Module Docs - Mimick/Impersonate plugin → [CLAUDE-mimick.md](CLAUDE-mimick.md) - Training module (AVT/CPT) → [CLAUDE-training.md](CLAUDE-training.md) - Payment module (Auth.net) → `includes-4honline/4h-membership-payment.php` (active development; no dedicated doc yet) - Background check plugin's Sterling Volunteers API → [CLAUDE-bgcheck-sterling-api.md](CLAUDE-bgcheck-sterling-api.md) (vendor API reference + status matrix + go-live gotchas; raw doc capture in `plugins/system/backgroundcheck/docs/`) Read those files when working on those features. --- ## Tooling ### Local model offload (Ollama) Before reading a large file/log/diff (>~3000 lines or >~200KB of bulk text) into context yourself, or before drafting repetitive mechanical edits across many files → [CLAUDE-ollama-offload.md](CLAUDE-ollama-offload.md). ### Subagent model Spawned Explore/lookup subagents → always pass `model: "haiku"`. ### Deploying to the live server / raw SSH - Committed-file deploys → `.claude/scripts/deploy-file.sh path/to/file` (refuses uncommitted/drifted files; drift-checks again right before writing). Read-only drift check alone → `.claude/scripts/check-server-drift.sh [files...]` (omit args to check everything). - For anything deploy-file.sh doesn't cover (deleting a remote file, `ls`/inspecting server state, one-off commands): `source .claude/scripts/lib/ssh-conn.sh` from repo root, then `ssh_run "shell command"`. File transfer helpers: `scp_get remote local` / `scp_put local remote`. `REMOTE_ROOT="public_html"` is the doc-root prefix for paths under it. - The library auto-prefers routing through WSL's OpenSSH (faster ControlMaster reuse); do not hand-roll a plain `ssh`/`scp` call — always go through `ssh_run`/`scp_get`/`scp_put` so that fallback logic stays in one place. ## claude-mem-lite — persistent memory PreToolUse hooks already run `mem_recall` for past lessons before Read/Edit/Write. The calls worth making proactively: | When | Call | |------|------| | Before Edit/Write | hook already recalled; if a `#NN` lesson was injected, cite `#NN` next time you produce user-visible text (citing = adopting the feedback; uncited lessons decay) | | After fixing a non-trivial bug | `mem_save(type="bugfix", lesson_learned="", importance=2)` | | After a non-obvious architecture decision | `mem_save(type="decision", lesson_learned="")` | | Deferring to a future session | `mem_defer({title, priority:1|2|3, detail})`; when fixed, add `closes_deferred=[N]` to `mem_save` | | Looking up past work / history | `mem_search "keywords"` · `mem_recent` · `mem_timeline` | Path cost is round-trips, not milliseconds: the PreToolUse hook above already recalls (0 calls) — prefer it. For an explicit query, if these `mem_*` tools are deferred behind ToolSearch this session, the Bash CLI (exact path in the detail doc) is one call vs two (ToolSearch + call). Full tool + CLI tables, citation/decay rules, and save discipline → `.claude/plugin_claude_mem_lite.md` --- ## AGENTIC EXECUTION WORKFLOW (LEAN SUPERPOWERS) ### 1. Brainstorm & Initial Spec - Vague tasks trigger an immediate brainstorm block. Ask clarifying questions and detail alternatives before writing any code. - Produce a compact initial approach covering proposed code architecture and target files. ### 2. Adversarial Review ("The Hole Finder") - **Mandatory Gate**: Before finalizing any plan or code, pivot to an adversarial developer persona whose sole job is to break the proposed solution. - Actively stress-test the initial spec against the stack constraints. Analyze and call out: - **Framework Gotchas**: Joomla 5/Fabrik limitations (e.g., placeholder parsing context, missing `jtbl_` references, evaluation order bugs). - **Database Bottlenecks**: Missing indices, multi-table joins on unindexed columns (like custom county repeat tables), PII leakage risks, or large queries that might trigger truncation limits. - **Edge Cases**: Empty states, unauthenticated sessions, unexpected user group IDs (e.g., County Admin vs. Club Manager permissions), or deployment drift. - **Alternatives**: Propose a cleaner, more stable, or lower-maintenance approach if the initial spec is overly complex. - Present these findings clearly as `[Gotchas & Edge Cases Identified]` and adjust the spec accordingly. ### 3. Linear Planning - Break the finalized, hardened spec into independent, 2-to-5-minute task increments. - Maintain this roadmap in a local file at `.claude/plan.md`. - Track tasks strictly: `[ ] Task description | Modified files | Verification criteria`. ### 4. Execution & TDD - Process tasks line-by-line. Focus entirely on the current micro-step without feature creep. - **Strict Testing Rule**: Write or update tests alongside code changes. Run and verify all test states inside the Local Docker Test Environment (`CLAUDE-docker-testenv.md`). ### 5. Code Review & Debug Routine - Evaluate every file change against the local plan before moving to the next item. - If a bug or crash occurs during execution, halt and apply this 4-step sequence: 1. Identify exact failing symptoms and collect relevant runtime logs. 2. Formulate a single, verifiable hypothesis. 3. Write a regression test or target a specific script to prove the bug exists. 4. Apply the fix and re-run your Docker validation suite to confirm resolution. ### 6. Finishing & Cleanup - Verify the entire test suite passes on your working branch. - Provide a concise summary of final modifications. - Offer to prepare the files for deployment using your custom deployment tools (`.claude/scripts/deploy-file.sh`).