ci: migrate default branch to main

.github/pull_request_template.md

@@ -17,7 +17,7 @@
 - [ ] Activation evidence covers affected child parts (screens, GUI statuses, text elements, and includes), not only main-source equality.
 - [ ] A safe manual ZTOAD smoke test passes on both systems, or the omitted system/check is explained below.
 - [ ] ST22 was checked before/after live smoke using an explicit dump ID/timestamp marker and client-side comparison; known and new dumps are distinguished.
-- [ ] Directly deployed objects on shared systems were restored to `master`, or an explicit temporary reservation is documented.
+- [ ] Directly deployed objects on shared systems were restored to `main`, or an explicit temporary reservation is documented.
 - [ ] ATC prerequisite/check errors were reviewed; an incomplete run is not reported as zero findings.
 - [ ] Authorization and SQL-injection implications were reviewed.
 - [ ] Security claims distinguish proven entry-point reachability from sink-level behavior and state actor prerequisites, or this is not applicable.

.github/workflows/quality.yml

@@ -1,10 +1,11 @@
 name: Quality
 
 on:
+  workflow_dispatch:
   pull_request:
   push:
     branches:
-      - master
+      - main
 
 permissions:
   contents: read

.github/workflows/release-please.yml

@@ -3,7 +3,7 @@ name: Release Please
 on:
   push:
     branches:
-      - master
+      - main
   workflow_dispatch:
 
 permissions:
@@ -12,7 +12,7 @@ permissions:
   pull-requests: write
 
 concurrency:
-  group: release-please-master
+  group: release-please-main
   cancel-in-progress: false
 
 jobs:
@@ -22,5 +22,6 @@ jobs:
       - name: Create or update the release pull request
         uses: googleapis/release-please-action@45996ed1f6d02564a971a2fa1b5860e934307cf7 # v5.0.0
         with:
+          target-branch: main
           config-file: release-please-config.json
           manifest-file: .release-please-manifest.json

AGENTS.md

@@ -4,7 +4,7 @@ These rules apply to every change in this repository. Read [docs/development.md]
 
 ## Sources of truth
 
-- GitHub `master` is the source of truth for released source and abapGit serialization.
+- GitHub `main` is the source of truth for released source and abapGit serialization.
 - Native abapGit is the source of truth for round-tripping complete SAP repository objects, including metadata XML, screens, text elements, authorization objects, tables, and transactions.
 - The ABAP 7.50 and S/4HANA 2023 systems are validation targets. Never treat an unexported system change as complete.
 - ARC-1 is the preferred interface for system context, focused object reads, syntax checks, ABAP Unit, and ATC. A source-only ARC-1 mirror is useful for inspection but is not a complete abapGit deployment.
@@ -21,24 +21,24 @@ These rules apply to every change in this repository. Read [docs/development.md]
 
 For changes that affect `src/` or live behavior:
 
-1. Start a short-lived `codex/<finding-id>` branch from current `master`. `master` remains the stable integration/release branch; never push a red or incomplete state to it. Keep the shared native-abapGit repository on `master` unless a structural-object test has an explicitly coordinated branch procedure.
+1. Start a short-lived `codex/<finding-id>` branch from current `main`. `main` remains the stable integration/release branch; never push a red or incomplete state to it. Keep the shared native-abapGit repository on `main` unless a structural-object test has an explicitly coordinated branch procedure.
 2. Start from a clean native-abapGit/system state, select one finding, research the issue and dependencies, reproduce it with sanitized inputs, and identify the root cause. Verify that every permanent test fixture and every serialized UI prerequisite needed by the smoke test exists on all claimed target releases.
 3. Add the smallest failing regression test and replay it against the original production code so the intended red failure is recorded.
 4. Write an implementation/test/rollback plan in `docs/plans/`, including ABAP 7.50 compatibility, Clean ABAP/Clean Core, abaplint, ABAP Unit, live activation/syntax/ATC, safe browser smoke, and ST22 delta. For security findings, distinguish demonstrated sink behavior from proven end-to-end entry-point reachability and state the actor prerequisites plus invariant without overclaiming. Review the plan before production changes.
 5. Implement the smallest change that turns the test green. Refactor only while the complete suite remains green. For frontend, database, authorization, or other environment-dependent assumptions, treat the first green implementation as a spike until a live integration test confirms it. Edit source locally for source-only changes; create structural SAP objects in a development system and export them with native abapGit instead of inventing serializer XML.
-6. Run `npm ci`, `npm test`, `git diff --check`, a complete diff review, and the relevant security/authorization review. Reconcile the review worklist against `git diff --name-only`; if a generic scanner or extension classifier omits an ABAP source file, add it explicitly rather than accepting partial coverage. When input is generated, wrapped, split, serialized, or otherwise transformed before execution, compare security semantics on both sides of that representation boundary; comments, quoting, escaping, length limits, and line/token boundaries must not hide behavior. Freeze the source/repository-object candidate in a commit before expensive live validation and record its commit plus source hash. Any subsequent `src/` or serialized-object change invalidates syntax, Unit, ATC, and smoke evidence and requires those affected gates to be rerun. Deploy the exact candidate to each available SAP target without pretending that the shared abapGit `master` link represents an unmerged branch.
-7. On SAP_BASIS 750 first when available, then S/4HANA 2023, require controlled activation, active syntax, all ABAP Unit tests, and complete ATC runs or explicit prerequisite failures. An ARC-1 write acknowledgement or `activate=true` request is not activation evidence: call activation explicitly, require active/inactive main-object equality, and query inactive child parts (including screens, GUI statuses, text elements, and includes) for every changed composite object. Main-source equality alone is not a pass when a child part remains inactive. Run a fresh-session safe browser smoke and ST22 delta on A4H only. Enter editor input with real user-like actions and the control's change/blur sequence; a DOM value set by automation is diagnostic only until the SAP backend executes that exact query. A generic browser error alone does not prove whether parsing, compilation, or runtime execution failed: pair it with a direct regression at the intended boundary and use a live fixture whose target grammar is already proven. If the SAP logon shell is entirely non-interactive in an automation browser, do not make it visible or submit it by DOM mutation; when the user did not require that browser, use an authenticated supported browser session, otherwise report the gate unavailable. Snapshot the latest dump ID/timestamp before smoke and compare the returned dump set client-side afterward; do not assume a diagnostic `from` filter was honored. A failed/unavailable gate is never a pass. After evidence is complete, restore every directly deployed object on a shared target to the intended `master` state and verify activation/object state, unless the maintainer explicitly reserves that candidate for the next task.
+6. Run `npm ci`, `npm test`, `git diff --check`, a complete diff review, and the relevant security/authorization review. Reconcile the review worklist against `git diff --name-only`; if a generic scanner or extension classifier omits an ABAP source file, add it explicitly rather than accepting partial coverage. When input is generated, wrapped, split, serialized, or otherwise transformed before execution, compare security semantics on both sides of that representation boundary; comments, quoting, escaping, length limits, and line/token boundaries must not hide behavior. Freeze the source/repository-object candidate in a commit before expensive live validation and record its commit plus source hash. Any subsequent `src/` or serialized-object change invalidates syntax, Unit, ATC, and smoke evidence and requires those affected gates to be rerun. Deploy the exact candidate to each available SAP target without pretending that the shared abapGit `main` link represents an unmerged branch.
+7. On SAP_BASIS 750 first when available, then S/4HANA 2023, require controlled activation, active syntax, all ABAP Unit tests, and complete ATC runs or explicit prerequisite failures. An ARC-1 write acknowledgement or `activate=true` request is not activation evidence: call activation explicitly, require active/inactive main-object equality, and query inactive child parts (including screens, GUI statuses, text elements, and includes) for every changed composite object. Main-source equality alone is not a pass when a child part remains inactive. Run a fresh-session safe browser smoke and ST22 delta on A4H only. Enter editor input with real user-like actions and the control's change/blur sequence; a DOM value set by automation is diagnostic only until the SAP backend executes that exact query. A generic browser error alone does not prove whether parsing, compilation, or runtime execution failed: pair it with a direct regression at the intended boundary and use a live fixture whose target grammar is already proven. If the SAP logon shell is entirely non-interactive in an automation browser, do not make it visible or submit it by DOM mutation; when the user did not require that browser, use an authenticated supported browser session, otherwise report the gate unavailable. Snapshot the latest dump ID/timestamp before smoke and compare the returned dump set client-side afterward; do not assume a diagnostic `from` filter was honored. A failed/unavailable gate is never a pass. After evidence is complete, restore every directly deployed object on a shared target to the intended `main` state and verify activation/object state, unless the maintainer explicitly reserves that candidate for the next task.
 8. Perform a final implementation review, update finding evidence, commit with a Conventional Commit subject, push the branch, open a pull request, and wait for required CI to become green.
 9. After the first green PR run, audit the plan, implementation, test evidence, CI output, and development process. Apply useful process/documentation improvements to the same PR, move its plan to `docs/plans/finished/`, push, and wait for CI again. Record the final green run in the PR description or a PR comment; do not create a new evidence-only commit that invalidates the checked head.
-10. Merge only after the maintainer accepts any recorded live-system limitations. Use GitHub's squash merge so the reviewed PR lands as one Conventional Commit; do not expose red/green/audit workflow commits on `master`. Pull the resulting `master`, verify Release Please behavior, and do not manually tag an ordinary release.
+10. Merge only after the maintainer accepts any recorded live-system limitations. Use GitHub's squash merge so the reviewed PR lands as one Conventional Commit; do not expose red/green/audit workflow commits on `main`. Pull the resulting `main`, verify Release Please behavior, and do not manually tag an ordinary release.
 
-For a source-only candidate, a controlled direct source deployment is preferable to switching the shared native-abapGit repository away from `master`. Record the candidate commit/hash and activate only the intended object. Structural changes still require a real native-abapGit round trip and may need a dedicated package/system to avoid changing shared objects underneath other work.
+For a source-only candidate, a controlled direct source deployment is preferable to switching the shared native-abapGit repository away from `main`. Record the candidate commit/hash and activate only the intended object. Structural changes still require a real native-abapGit round trip and may need a dedicated package/system to avoid changing shared objects underneath other work.
 
-When several PRs change the same ABAP object, keep them independently reviewable but integrate them sequentially. After each merge, rebase the next PR onto current `master`, resolve the source and test corpus deliberately, recompute aggregate findings/test counts, and rerun all affected local and live gates. Do not resolve a large overlap by accepting either side wholesale, and keep branch-specific counts in the finding plan/register rather than in long-lived workflow prose.
+When several PRs change the same ABAP object, keep them independently reviewable but integrate them sequentially. After each merge, rebase the next PR onto current `main`, resolve the source and test corpus deliberately, recompute aggregate findings/test counts, and rerun all affected local and live gates. Do not resolve a large overlap by accepting either side wholesale, and keep branch-specific counts in the finding plan/register rather than in long-lived workflow prose.
 
 For a coordinated structural-object round trip, refresh native abapGit before staging, review all system/Git drift, and select only the intended object. Never use **Add All** when unrelated changes are present. Review the staged filenames before commit, record every intentionally unselected drift item, push, refresh again, and require the intended object to be clean.
 
-When ARC-1's abapGit bridge is used to restore the shared repository branch, pass the full ref such as `refs/heads/master` and verify the result with a fresh repository read. A short branch value can return success without changing the selected branch on the current A4H bridge.
+When ARC-1's abapGit bridge is used to restore the shared repository branch, pass the full ref `refs/heads/main` and verify the result with a fresh repository read. A short branch value can return success without changing the selected branch on the current A4H bridge.
 
 For ZTOAD program installation evidence, run the repository installation contract through `npm test`. On a live structural target, capture `SAPRead(type="INACTIVE_OBJECTS")` as JSON and run `node scripts/installation-contract.mjs --inactive-objects <file>`. The live gate must show no `PROG/P`, `PROG/PCA`, `PROG/PS`, or `PROG/PX` part for ZTOAD before GUI/runtime smoke is considered valid.
 
@@ -56,7 +56,7 @@ NPL now has the complete ZTOAD object set in offline native-abapGit package `$ZT
 
 - New or changed non-GUI logic requires ABAP Unit coverage whenever technically feasible.
 - Follow red–green–refactor: reproduce and make a focused test fail before changing production behavior.
-- Existing open defects belong in the findings register; do not keep permanently failing or disabled regression tests on `master`.
+- Existing open defects belong in the findings register; do not keep permanently failing or disabled regression tests on `main`.
 - Put report test classes at the end of the program and declare them `FOR TESTING RISK LEVEL HARMLESS DURATION SHORT`.
 - Prefer data-in/data-out parser and generator units with no database commits, user-specific state, frontend GUI, or persistent fixtures.
 - Extract testable logic behind small local classes instead of adding more behavior to large `FORM` routines.

CONTRIBUTING.md

@@ -16,17 +16,17 @@ The pinned abaplint version parses the abapGit files, checks serializer consiste
 ## Develop a change
 
 1. Open or link an issue. Bug reports should contain a minimal sanitized query, exact error, ZTOAD version, SAP_BASIS/support-package level, and database.
-2. Select one ID from [docs/baseline-findings.md](docs/baseline-findings.md) or add a new finding. The current maintainer workflow stays on `master`; keep red/incomplete work local and never push a known-red state.
+2. Select one ID from [docs/baseline-findings.md](docs/baseline-findings.md) or add a new finding. Start a short-lived branch from current `main`; keep red evidence on that branch and never merge a known-red state.
 3. Add a focused failing regression test before changing production behavior. Follow the full [TDD strategy](docs/test-strategy.md).
 4. For source-only changes, edit the serialized ABAP source locally. For a new object, screen, transaction, DDIC definition, or other structural metadata, make the change in a development SAP system and export it with native abapGit.
 5. Make the smallest fix, run `npm test`, and perform the two live-system gates described below.
-6. Commit with a Conventional Commit subject such as `fix: parse CASE expressions in aggregates` or `feat: add transaction code`. Push `master` only after the required gates are green.
+6. Commit with a Conventional Commit subject such as `fix: parse CASE expressions in aggregates` or `feat: add transaction code`. Push the short-lived branch, open a pull request to `main`, require green checks, and squash merge with a Conventional Commit title.
 
 Do not hand-author abapGit XML for a new or structurally changed SAP object. The serializer output is release- and object-type-sensitive; let native abapGit generate it, then review it in Git.
 
 ## Live validation
 
-Test the local/`master` state on both targets, in this order:
+Test the exact candidate based on current `main` on both targets, in this order:
 
 1. ABAP 7.50: native-abapGit pull or controlled ARC-1 source deployment, activation, syntax, ABAP Unit, ATC, safe manual ZTOAD smoke test, and ST22 delta check.
 2. S/4HANA 2023: repeat the same checks and watch for behavior changes in the newer ABAP SQL parser/runtime.
@@ -35,11 +35,11 @@ Record the system release, ATC variant, and result in the pull request. Never pa
 
 ## Commit and release conventions
 
-Release Please derives versions and release notes from commits on `master`:
+Release Please derives versions and release notes from squash commits on `main`:
 
 - `fix:` → patch release
 - `feat:` → minor release
 - `feat!:` or a `BREAKING CHANGE:` footer → major release
 - `docs:`, `test:`, `ci:`, `refactor:`, and `chore:` describe non-release work unless the commit includes a releasable footer
 
-If the project later moves to pull requests, prefer squash merging so the pull-request title becomes one deliberate release-note entry. With the current direct-`master` workflow, the Conventional Commit subject becomes the release-note entry. Release Please updates a release PR; merging that release PR creates the GitHub tag and release.
+Every change uses a pull request and squash merge so its title becomes one deliberate release-note entry. Release Please updates a separate release PR; merging that release PR creates the GitHub tag and release.

docs/baseline-findings.md

@@ -2,6 +2,10 @@
 
 _Snapshot: 2026-08-07 · candidate `92946fe` from merged master `a5ad27c` · live system A4H client 001, SAP_BASIS 758 SP02 · secondary target NPL client 001, SAP_BASIS 750 SP02_
 
+The GitHub default branch was renamed from `master` to `main` after this dated
+evidence was recorded. Historical commit/branch wording in this register is
+preserved; all new work starts from `main`.
+
 This is the ordered work list for incremental TDD. It records observed defects separately from broad style debt so a new failure cannot disappear inside the legacy backlog. A finding is closed only after its regression test is green locally where possible, green on A4H, and green on the SAP_BASIS 750 target.
 
 ## Baseline evidence