GORM: Shared Mapping Registry O(M+N) Scaling

.agents/skills/test-fixer/SKILL.md

@@ -89,6 +89,68 @@ All tests passed! 🎉
 
 ---
 
+## Isolated Testing (local.properties)
+
+The project supports an **Isolation Mode** for focused development. By configuring `local.properties`, you can limit test execution to specific modules and enable aggressive heap settings for those tests.
+
+### Configuration
+
+In `local.properties`:
+```properties
+# List the modules you want to focus on
+grails.test.modules=:grails-datamapping-core-test,:grails-data-simple
+```
+
+### Usage
+
+```bash
+# Runs ONLY the modules defined in grails.test.modules
+# Automatically aggregates failures and style violations
+# MANDATORY: Must include the local-init.gradle initialization script
+./gradlew -I local-init.gradle testSelected
+```
+
+When `testSelected` is run:
+- Only tests in the specified modules are enabled.
+- `maxParallelForks` is set to `1` (serial) for stability.
+- Heap size is increased to `3g`.
+- `ignoreFailures` is set to `true` to ensure aggregation tasks run.
+- Non-selected modules have their test and quality tasks disabled.
+
+---
+
+## Iterative Test Fixing Workflow
+
+When tasked with fixing a large number of test failures (especially in isolation mode), adhere to this highly efficient, iterative loop:
+
+**Step 1: The Initial Assessment**
+Run the full isolated test suite once to generate the master list of all current failures in `TEST_FAILURES.md`.
+```bash
+./gradlew -I local-tasks.gradle clean testSelected aggregateTestFailures
+```
+
+**Step 2: The Inner Loop (One by One)**
+Take the generated list of failures and iterate through it **one test at a time**.
+For *each* individual test (or closely related group of tests in the same class) on the list:
+1. Investigate the specific failure.
+2. Apply a targeted code fix.
+3. Verify the fix by running **only that single test** to maintain a fast feedback loop. Do NOT rerun the entire suite.
+```bash
+./gradlew :<module_name>:test --tests "<fully_qualified_class_name>.<test_method_name>"
+```
+4. Once that single test passes locally, move on to the *next* failing test on the list and repeat the process.
+
+**Step 3: The Outer Loop (Full Verification)**
+Only after you have gone through the entire list and fixed every test *individually* in the inner loop, run the full aggregated suite again to verify no regressions were introduced and to update the master list.
+```bash
+./gradlew -I local-tasks.gradle clean testSelected aggregateTestFailures
+```
+
+**Step 4: Iterate**
+If the full suite reveals any new or remaining failures in `TEST_FAILURES.md`, repeat the entire process starting from Step 2, continuing until the final aggregated run produces zero failures.
+
+---
+
 ## Interpreting Failures
 
 Each row in the table gives you:
@@ -186,3 +248,34 @@ Gradle writes JUnit XML test results to:
 ```
 
 `aggregateTestFailures` scans all these directories automatically.
+
+# Iterative Test Fixing Workflow
+
+When tasked with fixing a large number of test failures (especially in isolation mode), adhere to this highly efficient, iterative loop:
+
+**Step 1: The Initial Assessment**
+Run the full isolated test suite once to generate the master list of all current failures in `TEST_FAILURES.md`.
+```bash
+./gradlew -I local-tasks.gradle clean testSelected aggregateTestFailures
+```
+
+**Step 2: The Inner Loop (One by One)**
+Take the generated list of failures and iterate through it **one test at a time**.
+For *each* individual test (or closely related group of tests in the same class) on the list:
+1. Investigate the specific failure.
+2. Apply a targeted code fix.
+3. Verify the fix by running **only that single test** to maintain a fast feedback loop. Do NOT rerun the entire suite.
+```bash
+./gradlew :<module_name>:test --tests "<fully_qualified_class_name>.<test_method_name>"
+```
+4. Once that single test passes locally, move on to the *next* failing test on the list and repeat the process.
+
+**Step 3: The Outer Loop (Full Verification)**
+Only after you have gone through the entire list and fixed every test *individually* in the inner loop, run the full aggregated suite again to verify no regressions were introduced and to update the master list.
+```bash
+./gradlew -I local-tasks.gradle clean testSelected aggregateTestFailures
+```
+
+**Step 4: Iterate**
+If the full suite reveals any new or remaining failures in `TEST_FAILURES.md`, repeat the entire process starting from Step 2, continuing until the final aggregated run produces zero failures.
+

AGENTS.md

@@ -54,6 +54,7 @@ export GRADLE_OPTS="-Xms2G -Xmx5G"
 11. **Every code touch must update all tests for the changed class** - When a class is modified, find and update every test that covers it — unit, integration, and TCK. Do not leave any existing test out of sync with the new code.
 12. **Clean violations before commit** - Before every automated commit, run `./gradlew clean aggregateStyleViolations test aggregateTestFailures --continue` from the root and ensure that `CHECKSTYLE_VIOLATIONS.md`, `CODENARC_VIOLATIONS.md`, `PMD_VIOLATIONS.md`, and `TEST_FAILURES.md` report no issues and are removed.
 13. **Mandatory test coverage** - Any class touched in a commit MUST be covered with tests that verify all behavior. You must run ALL tests in the affected module(s) and ensure they pass before committing.
+14. **NEVER delete `local*` files and DO NOT remove values** - Files prefixed with `local` (e.g., `local.properties`, `local-tasks.gradle`) must NEVER be deleted. When modifying these files, NEVER remove existing values; instead, comment them out and append new values to maintain history and prevent loss of local configuration.
 
 ## Available Skills
 
@@ -267,6 +268,11 @@ See `CONTRIBUTING.md` for full details.
 | Deprecation details | `./gradlew <task> --warning-mode all` |
 
 
+## Local Configuration
+
+- **Local File Preservation**: NEVER delete files prefixed with `local` (e.g., `local.properties`, `local-tasks.gradle`). These files are used for local developer overrides and environment-specific tasks and must be maintained.
+- **Commenting over Deletion**: When instructed to modify any `local*` files or similar configuration files, DO NOT delete the existing lines. Instead, comment out the old entries and append the new ones. This ensures a traceable history of local configuration changes.
+
 ### Reporting Vulnerabilities
 
 Please see the page of the [ASF Security Team](https://www.apache.org/security/) for further information and contact information.
@@ -278,4 +284,6 @@ Please see the page of the [ASF Security Team](https://www.apache.org/security/)
 - **Spock 2.3 Docs**: https://spockframework.org/spock/docs/2.3/all_in_one.html
 - **GORM Docs**: https://grails.apache.org/docs/latest/grails-data/
 - **Issues**: https://github.com/apache/grails-core/issues
-- **Slack**: https://grails.slack.com
+
+## Agent Commit Policy
+When committing changes assisted by an AI agent, you MUST include a note in the commit message stating that the agent acted as a collaborator and that the user (borinquenkid) is the primary author and remains responsible for the changes. Do not present the agent as the sole author of the code.