From 3ecf7c74840d85ce2246124a92092bbb01ce4bf8 Mon Sep 17 00:00:00 2001 From: marianfoo <13335743+marianfoo@users.noreply.github.com> Date: Fri, 7 Aug 2026 18:29:25 +0200 Subject: [PATCH 1/2] ci: migrate default branch to main --- .github/pull_request_template.md | 2 +- .github/workflows/quality.yml | 3 +- .github/workflows/release-please.yml | 5 +- AGENTS.md | 18 ++--- CONTRIBUTING.md | 10 +-- docs/baseline-findings.md | 4 + docs/development.md | 20 ++--- docs/plans/abaplint-zero-findings.md | 2 +- docs/plans/default-branch-main.md | 78 ++++++++++++++++++ ...26-08-07-arc1-abapgit-integration-audit.md | 4 +- ...026-08-07-default-branch-main-migration.md | 81 +++++++++++++++++++ docs/setup-evaluation.md | 16 ++-- docs/test-strategy.md | 8 +- scripts/repository-contract.mjs | 56 ++++++++++++- system-info.md | 10 +-- 15 files changed, 269 insertions(+), 48 deletions(-) create mode 100644 docs/plans/default-branch-main.md create mode 100644 docs/research/2026-08-07-default-branch-main-migration.md diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 0ab1efd..66c1613 100644 --- a/.github/pull_request_template.md +++ b/.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. diff --git a/.github/workflows/quality.yml b/.github/workflows/quality.yml index b489500..54111f4 100644 --- a/.github/workflows/quality.yml +++ b/.github/workflows/quality.yml @@ -1,10 +1,11 @@ name: Quality on: + workflow_dispatch: pull_request: push: branches: - - master + - main permissions: contents: read diff --git a/.github/workflows/release-please.yml b/.github/workflows/release-please.yml index a4c8e8c..aa9d1b1 100644 --- a/.github/workflows/release-please.yml +++ b/.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 diff --git a/AGENTS.md b/AGENTS.md index 6985078..69497c9 100644 --- a/AGENTS.md +++ b/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/` 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/` 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 `. 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. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 88fec8d..d090899 100644 --- a/CONTRIBUTING.md +++ b/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. diff --git a/docs/baseline-findings.md b/docs/baseline-findings.md index 3d30380..274910b 100644 --- a/docs/baseline-findings.md +++ b/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 diff --git a/docs/development.md b/docs/development.md index e3dcadc..c61547f 100644 --- a/docs/development.md +++ b/docs/development.md @@ -51,13 +51,13 @@ Setup procedure: 1. Open transaction `ZABAPGIT`. 2. Create an online repository for `https://github.com/marianfoo/ztoad`. -3. Select `master` for the initial installation and bind it to the chosen empty package. Keep this shared repository on `master` during normal source-only PR testing. +3. Select `main` for the initial installation and bind it to the chosen empty package. Keep this shared repository on `main` during normal source-only PR testing. 4. Pull and activate all objects. 5. Query inactive objects and require the ZTOAD installation-closure command above to pass. Main-source equality is insufficient for a composite program. 6. Confirm that the repository status is clean. 7. Run ZTOAD once with the read-only smoke query below. -If the ARC-1 abapGit bridge is used to restore the shared branch after a coordinated round trip, pass `refs/heads/master`, not only `master`, and verify the selected branch with a fresh `list_repos` call. On the current A4H bridge the short value returned success without changing the repository, while the full ref switched it correctly. Re-run the inactive-child contract after restoration. +If the ARC-1 abapGit bridge is used to restore the shared branch after a coordinated round trip, pass `refs/heads/main`, not only `main`, and verify the selected branch with a fresh `list_repos` call. On the current A4H bridge a short branch value previously returned success without changing the repository, while the full ref switched it correctly. Re-run the inactive-child contract after restoration. On A4H, load the private system base URL from the ignored `.env` file as `SAP_URL`. The Fiori-shell URL for the transaction is: @@ -70,11 +70,11 @@ For an offline NPL refresh, create an offline repository bound to the dedicated Current ARC-1 TABL `dryRun` requests can still create an inactive draft. After any DDIC dry-run or preflight, compare active/inactive object state immediately; never infer non-mutation from the option name or success text. The A4H abapGit ADT backend also uses version-specific staging/pull XML namespaces, so an empty ARC-1 stage result is not proof of a clean repository—verify the raw bridge result or native client before pushing. -## 4. Local-first TDD flow with a stable `master` +## 4. Local-first TDD flow with a stable `main` -`master` remains the only long-lived integration/release line and the normal branch of each shared native-abapGit link. Development uses a short-lived pull-request branch so CI and review can evaluate the candidate without placing an unreviewed state on `master`. +`main` is the only long-lived integration/release line and the normal branch of each shared native-abapGit link. Development uses a short-lived pull-request branch so CI and review can evaluate the candidate without placing an unreviewed state on `main`. -1. Synchronize local `master`, create `codex/`, select one finding, and confirm the target systems have no unrelated differences. +1. Synchronize local `main`, create `codex/`, select one finding, and confirm the target systems have no unrelated differences. 2. Research and reproduce the problem on the oldest available affected system. Check fixture and serialized UI-metadata availability before making a spike permanent. 3. Add the smallest test, replay the original production code, and record the intended red failure. 4. Write and review a plan under `docs/plans/` covering implementation, ABAP 7.50, Clean ABAP/Clean Core, local/live tests, rollback, browser smoke, and ST22. A security plan must separately state actor prerequisites, proven entry-point reachability, demonstrated sink behavior, and the invariant enforced by the patch so a sink-level proof is not presented as an end-to-end exploit without evidence. @@ -86,7 +86,7 @@ Current ARC-1 TABL `dryRun` requests can still create an inactive draft. After a and test every downstream representation so later generation cannot silently restore the bypass. 6. Run `npm ci`, `npm test`, `git diff --check`, and the final local/security review. Reconcile the review inventory with `git diff --name-only`; generic extension classifiers can omit `.abap`, so every changed ABAP source must be added explicitly and reviewed. For generated or otherwise transformed input, compare pre- and post-transformation semantics, especially comments, quoting, escaping, length limits, and inserted line/token boundaries. Commit and freeze the exact source/object candidate before the expensive live gates, and record its commit plus source hash. Any later `src/` or serialized-object change invalidates the affected live evidence and must be redeployed and rechecked. -7. Deploy the exact candidate source to SAP_BASIS 750 first through ARC-1/ADT when its real dependencies exist; record any missing ADT prerequisite as blocked. Keep the A4H native-abapGit link on `master` and record an unmerged candidate as a direct deployment. Follow every write with an explicit activation call, active/inactive main-object comparison, and an inactive-child-part query for affected composite objects; a write response, activation option, or equal main-source hash alone does not prove that screens, statuses, texts, and includes are active. +7. Deploy the exact candidate source to SAP_BASIS 750 first through ARC-1/ADT when its real dependencies exist; record any missing ADT prerequisite as blocked. Keep the A4H native-abapGit link on `main` and record an unmerged candidate as a direct deployment. Follow every write with an explicit activation call, active/inactive main-object comparison, and an inactive-child-part query for affected composite objects; a write response, activation option, or equal main-source hash alone does not prove that screens, statuses, texts, and includes are active. 8. On NPL, activate only the intended object and run active syntax, all ABAP Unit tests, and complete ATC variants through ARC-1. On A4H/SAP_BASIS 758, repeat those checks and additionally start a fresh browser session for safe smoke and ST22 delta. Verify required dynpros/GUI statuses before attributing an end-to-end failure to the source candidate. 9. If a correction must be made in SAP, export it through native abapGit or reproduce it locally, then review every serialized/source difference. Never leave an unexported system-only fix. 10. Perform a final review, update evidence, commit/push the short-lived branch, open the PR, and wait for CI. After the first green run, audit the process/CI, update guidance in the same PR, move the plan to `docs/plans/finished/`, push, and wait again. Put the final run link in the PR description/comment after it passes; committing that run ID would create a new unchecked head and an avoidable CI loop. After maintainer acceptance, use GitHub's squash merge so the PR lands as one Conventional Commit even though its branch preserves red/green/audit history. @@ -95,9 +95,9 @@ Always test 7.50 first. A change that uses newer syntax may appear correct on 20 Native abapGit branch switching changes real system objects, and abapGit Flow remains beta. Do not use either casually in the shared package. Structural-object PRs may require a dedicated package/system or an explicitly coordinated temporary branch procedure. -A direct candidate deployment changes shared mutable state even when the native-abapGit link remains on `master`. After collecting the evidence, redeploy and explicitly activate the intended `master` object, then verify syntax, the relevant Unit baseline, and active/inactive state. The only exception is an explicit maintainer reservation for immediate follow-up work, recorded with the deployed commit/hash. +A direct candidate deployment changes shared mutable state even when the native-abapGit link remains on `main`. After collecting the evidence, redeploy and explicitly activate the intended `main` object, then verify syntax, the relevant Unit baseline, and active/inactive state. The only exception is an explicit maintainer reservation for immediate follow-up work, recorded with the deployed commit/hash. -For concurrent PRs that touch the same report, merge one at a time. Rebase the next branch onto the new `master`, combine the production logic and complete test corpus deliberately, recompute aggregate finding/test counts, and rerun affected local/live gates. Long-lived playbooks describe the policy; exact branch counts belong in the finding register and finished plan so parallel PRs do not overwrite one another with incompatible snapshots. +For concurrent PRs that touch the same report, merge one at a time. Rebase the next branch onto the new `main`, combine the production logic and complete test corpus deliberately, recompute aggregate finding/test counts, and rerun affected local/live gates. Long-lived playbooks describe the policy; exact branch counts belong in the finding register and finished plan so parallel PRs do not overwrite one another with incompatible snapshots. If ARC-1's pre-write linter reports an incorrect ABAP release, do not weaken all write checks. After the pinned repository abaplint gate passes, disable only the mis-profiled local lint request, retain server preflight, activate explicitly, and run SAP syntax/Unit/ATC/object-state checks. Track the tool mismatch separately from the product change. @@ -224,14 +224,14 @@ Run ATC security checks on the live systems. Local abaplint cannot prove runtime ## 9. Release flow -Release Please runs on pushes to `master` and reads Conventional Commit messages. The repository starts from version `4.0.4`; its manifest avoids replaying old history. It maintains: +Release Please runs on pushes to `main` and reads Conventional Commit messages. The repository starts from version `4.0.4`; its manifest avoids replaying old history. It maintains: - `CHANGELOG.md` - `version.txt` - the annotated version in `README.md` - the annotated version comment in `src/ztoad.prog.abap` -When a `fix:` or `feat:` change reaches `master`, Release Please opens or updates one release PR. Review its version and changelog, let Quality pass, and merge it to create the unprefixed SemVer tag and GitHub Release. The action intentionally uses the repository `GITHUB_TOKEN` by default. GitHub places the resulting pull-request Quality workflow in an approval-required state; a maintainer must approve that run and wait for green CI. See [setup-evaluation.md](setup-evaluation.md) before switching to a GitHub App or fine-grained PAT for unattended triggering. +When a `fix:` or `feat:` change reaches `main`, Release Please opens or updates one release PR targeted explicitly at `main`. Review its version and changelog, let Quality pass, and merge it to create the unprefixed SemVer tag and GitHub Release. The action intentionally uses the repository `GITHUB_TOKEN` by default. GitHub places the resulting pull-request Quality workflow in an approval-required state; a maintainer must approve that run and wait for green CI. See [setup-evaluation.md](setup-evaluation.md) before switching to a GitHub App or fine-grained PAT for unattended triggering. ## 10. Primary references diff --git a/docs/plans/abaplint-zero-findings.md b/docs/plans/abaplint-zero-findings.md index 948ddaf..d20ed30 100644 --- a/docs/plans/abaplint-zero-findings.md +++ b/docs/plans/abaplint-zero-findings.md @@ -1,6 +1,6 @@ # Plan: reduce the full abaplint inventory to zero -_Status: active · Initial baseline: 1,857 findings in 57 default rules on 2026-08-06 · integrated `master` `2360fe4` checkpoint: 2,051 findings in 61 rules on 2026-08-07_ +_Status: active · Initial baseline: 1,857 findings in 57 default rules on 2026-08-06 · integrated default-branch `2360fe4` checkpoint: 2,051 findings in 61 rules on 2026-08-07_ ## Goal diff --git a/docs/plans/default-branch-main.md b/docs/plans/default-branch-main.md new file mode 100644 index 0000000..17c35a8 --- /dev/null +++ b/docs/plans/default-branch-main.md @@ -0,0 +1,78 @@ +# Migrate the default branch to `main` + +_Date: 2026-08-07 · branch: `codex/default-branch-main`_ + +## Goal + +Rename the repository's stable integration/release branch from `master` to +`main` without losing commits, breaking CI or Release Please, invalidating the +open release PR, or leaving local and native-abapGit clients on an obsolete ref. + +## Reviewed plan + +1. Record the exact starting commit, GitHub default, open PR base, workflow + filters, merge policy, protection/ruleset state, and native-abapGit branch. +2. Research GitHub's supported rename semantics and Release Please's explicit + target-branch behavior; record the decision and rollback. +3. Create this migration branch from the exact old default head. +4. Rename the GitHub default branch through the supported API. Verify the new + default, remote refs, PR #23 base, and absence of a remote `master` branch. +5. Rename the local integration branch, set it to track `origin/main`, refresh + `origin/HEAD`, and keep this work on the short-lived migration branch. +6. Update current operational instructions, contribution guidance, PR template, + Quality trigger, Release Please trigger/target/concurrency, active plans, and + system context. Preserve old branch names in dated research and finished + plans as historical evidence, with an explicit migration note explaining + that choice. +7. Switch the A4H native-abapGit repository to `refs/heads/main` and reread it. + Record that NPL is offline and future ZIPs come from `origin/main`. +8. Run `npm ci`, `npm test`, `git diff --check`, YAML/config parsing, branch- + reference audits, and a complete diff review. ABAP/live behavior gates are + not applicable because `src/` and SAP repository objects do not change. +9. Push the migration branch, open a draft PR to `main`, and require the normal + Quality checks to pass. +10. Audit the first green run and documentation, apply any durable correction, + archive this plan, and wait for a second green run when the head changes. +11. Squash merge, update local `main`, verify `origin/main` equality and + `origin/HEAD`, then verify the main-push Quality and Release Please runs. +12. Require one green release PR based on `main`; preserve it unmerged. + +## Execution record + +- GitHub renamed exact default head + `b6acc143e09590a48e3fef5b9ac3fda85834de0e` from `master` to `main`. + `origin/master` no longer exists; local `main` tracks `origin/main`, and + `origin/HEAD` resolves to `origin/main`. +- GitHub automatically retargeted Release Please PR #23 from `master` to + `main`, preserving its head and green checks. +- A4H native abapGit repository `000000000017` was switched with full ref + `refs/heads/main`. A fresh connector read proves that selected branch, and + the repository check endpoint is green. No pull or activation occurred. +- NPL remains an offline repository; its next reviewed ZIP source is + `origin/main`. +- `npm ci`, `npm test`, configured abaplint, repository/install contracts, + `git diff --check`, Node syntax, and YAML parsing are green. The repository + contract now guards the `main` push filters, Release Please target/concurrency, + and current operational guidance against branch-name regression. +- The branch-reference audit leaves `master` only in this migration record, + dated evidence/finished plans, and the README/CHANGELOG phrase "master + language," which describes localization rather than a Git branch. +- SAP syntax, Unit, ATC, WebGUI, and ST22 are not applicable: no file under + `src/`, no serialized SAP object, and no live behavior changed. + +## Compatibility and risk review + +- **ABAP 7.50 / Clean ABAP / Clean Core:** no ABAP or serialized object changes; + all SAP gates are not applicable with that reason. +- **CI:** pull-request Quality is intentionally branch-agnostic and should run + on the migration PR; push Quality is changed explicitly to `main`. +- **Release:** an explicit `target-branch: main` avoids relying on default-branch + inference. PR #23 is never merged during this migration. +- **History:** replacing branch names inside old evidence would make it false; + only current instructions and active records are updated. +- **Rollback:** follow the reversible rename and configuration procedure in the + research note before new work diverges from `main`. + +## Reference + +- [Migration research](../research/2026-08-07-default-branch-main-migration.md) diff --git a/docs/research/2026-08-07-arc1-abapgit-integration-audit.md b/docs/research/2026-08-07-arc1-abapgit-integration-audit.md index feea68b..7dc4a23 100644 --- a/docs/research/2026-08-07-arc1-abapgit-integration-audit.md +++ b/docs/research/2026-08-07-arc1-abapgit-integration-audit.md @@ -28,7 +28,9 @@ _Observed 2026-08-06 to 2026-08-07 with ARC-1 1.0.2, A4H SAP_BASIS 758 SP02, nat ## Safe workflow until those gaps are fixed 1. Probe the system and repository in the same ARC-1 process when possible. -2. Use full branch refs such as `refs/heads/master` and reread repository details after every switch. +2. Use the repository's current full branch ref, now `refs/heads/main`, and + reread repository details after every switch. The original reproduction used + `refs/heads/master` before the default-branch rename. 3. Enable write scope only for genuine mutations and provide remote credentials through the approved secret channel; never print them. 4. Stage explicit object selections, review returned filenames, and never use **Add All** with unrelated drift. 5. Treat native abapGit as the complete serializer and ARC-1 source writes as source-only unless the exact child-object closure is independently proven. diff --git a/docs/research/2026-08-07-default-branch-main-migration.md b/docs/research/2026-08-07-default-branch-main-migration.md new file mode 100644 index 0000000..8e46b79 --- /dev/null +++ b/docs/research/2026-08-07-default-branch-main-migration.md @@ -0,0 +1,81 @@ +# Default branch migration from `master` to `main` + +_Researched: 2026-08-07_ + +## Starting state + +- GitHub default branch: `master` at `b6acc143e09590a48e3fef5b9ac3fda85834de0e`. +- Repository branch protection and repository rulesets: none. +- Merge policy: squash only; merged branches are deleted automatically. +- Release Please PR #23 targets `master` and is green at version `5.0.1`. +- Quality runs for every pull request and for pushes to `master`. +- Release Please runs for pushes to `master` and by manual dispatch. +- The shared online A4H native-abapGit repository uses the full branch ref + `refs/heads/master`. NPL uses an offline ZIP repository and has no online + branch to switch. + +## Authoritative behavior + +GitHub documents two related operations: changing the default to another +existing branch and renaming a branch. Renaming the default branch is the safer +fit here because GitHub updates the default branch, open pull-request bases, +branch-protection policies, and normal repository URL redirects together. +Collaborators must still update local tracking, and raw-content URLs do not +redirect. + +GitHub also states that Actions workflow references are not rewritten by a +branch rename. ZTOAD must therefore change both workflow push filters itself. +Release Please documents `target-branch` as the branch against which it opens a +release PR; setting it explicitly to `main` removes ambiguity after the rename. + +Sources: + +- [GitHub: Renaming a branch](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch) +- [GitHub: Changing the default branch](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/changing-the-default-branch) +- [Release Please Action inputs](https://github.com/googleapis/release-please-action#action-inputs) + +## Migration decisions + +1. Create the migration branch from the exact old default head. +2. Rename the GitHub branch through the supported API, then update the local + integration branch and `origin/HEAD` using GitHub's documented commands. +3. Update Quality and Release Please to use `main`; configure Release Please's + target explicitly and rename its concurrency group. +4. Update current operational documentation and templates. Do not rewrite + dated research or finished plans whose `master` references are historical + evidence from before this migration. +5. Verify that PR #23 follows the new base. After the migration reaches `main`, + run Release Please and require one current green release PR. Do not merge the + release PR as part of the branch migration. +6. Switch the online A4H abapGit repository with the full ref + `refs/heads/main` and reread it to prove the postcondition. NPL's next + reviewed offline ZIP must be generated from `origin/main`. + +The switch was performed through a bounded ARC-1 1.0.2 process after an +explicit feature probe. The first cold-process call returned `isError: true` +and made no change; the persistent probe/switch sequence returned `ok: true`. +A separate fresh `list_repos` read then reported repository `000000000017` on +`refs/heads/main`, and the abapGit check endpoint returned `ok: true`. Switching +the selected ref did not pull or activate SAP objects. + +## Validation and rollback + +This is a GitHub/tooling/documentation migration. It changes no ABAP source, +serialized SAP object, or live behavior, so SAP syntax, Unit, ATC, browser, and +ST22 gates are not applicable. The repository's local and GitHub Quality gates +remain mandatory. + +Validation requires: + +- GitHub and `origin/HEAD` report `main` as the default; +- `origin/main` and local `main` identify the same commit; +- no remote `master` branch remains after the rename; +- a pull request to `main` receives the normal Quality checks; +- a push/dispatch on `main` runs Release Please against `main`; +- the release PR is green and has one unambiguous base; +- the A4H native-abapGit repository reports `refs/heads/main` after a fresh read. + +If the migration must be rolled back before dependent work starts, use the same +GitHub rename operation from `main` to `master`, restore the workflow filters and +Release Please target in a reviewed change, restore local tracking and +`origin/HEAD`, and switch A4H abapGit back with the verified full ref. diff --git a/docs/setup-evaluation.md b/docs/setup-evaluation.md index 7c96f14..f0abf09 100644 --- a/docs/setup-evaluation.md +++ b/docs/setup-evaluation.md @@ -45,7 +45,7 @@ Potential change: a dedicated GitHub App installation token or fine-grained PAT ### 5. Branch concurrency inside SAP -Current decision: keep `master` as the only long-lived integration/release branch and keep native abapGit repository `000000000017` linked to it. Develop each finding on a short-lived pull-request branch. For source-only candidates, deploy the exact source directly and record the candidate commit instead of switching the shared SAP repository branch. +Current decision: keep `main` as the only long-lived integration/release branch and keep native abapGit repository `000000000017` linked to it. Develop each finding on a short-lived pull-request branch. For source-only candidates, deploy the exact source directly and record the candidate commit instead of switching the shared SAP repository branch. Structural-object branches need a dedicated package/system or an explicitly coordinated branch switch because native abapGit changes the real system objects. abapGit Flow can map filtered Git operations to transports, but its documentation marks it beta, so it is not enabled. @@ -61,15 +61,15 @@ Recommendation: extract query parser/generator units issue by issue, beginning w Alternative: a full OO rewrite could improve design faster but greatly expands regression risk and makes cross-release comparison harder. -### 8. Historical `4.0.4` tag +### 8. Historical `4.0.4` tag — resolved -Current code and documentation identify version `4.0.4`, but Git contains only the `4.0.3` tag. The Release Please manifest starts at the declared code version `4.0.4`; current PR #10 correctly proposes `4.1.0` because the accumulated conventional commits include a feature. Its first generated compare link still assumes that a `4.0.4` tag exists. +The one-time immutable `4.0.4` tag now exists, so Release Please compare links +have their required baseline. Release Please subsequently created release and +tag `5.0.0`. Do not recreate or move either tag. -Recommendation: after the current `master` state has passed both live-system gates, create a one-time `4.0.4` tag and GitHub Release at the exact verified commit. Do not backfill it before live verification, and do not move the tag later. +### 9. Protecting `main` -### 9. Protecting `master` - -The GitHub API currently reports that `master` is not protected. Recommendation: after the pull-request workflow has been used successfully, require pull requests and the `abaplint (ABAP 7.50)` Quality check, block force pushes/deletion, and decide whether maintainer approval is required for a single-maintainer repository. +The GitHub API reports that `main` is not protected. Recommendation: require pull requests and the `Repository quality (ABAP 7.50)` check, block force pushes/deletion, and decide whether maintainer approval is required for a single-maintainer repository. This is not changed automatically in the bug PR because repository rules are external policy, can lock out emergency maintenance if configured incorrectly, and need the maintainer's explicit approval. @@ -83,7 +83,7 @@ Recommendation: retain report-local tests until parser/generator areas are extra ### 12. Full abaplint gate -Exact integrated master `2360fe4` has 2,051 findings across 61 rules; the `BASE-RUN-006` candidate is 2,109 across the same 61 rules. `npm run lint:quality` reproduces the inventory without making every PR red. Recommendation: burn the list down in correctness/architecture/mechanical phases and add `npm run lint:quality -- --strict` to required CI only when it reaches zero. See the [research](research/2026-08-06-abaplint-quality-roadmap.md) and [active plan](plans/abaplint-zero-findings.md). +Exact integrated default-branch checkpoint `2360fe4` has 2,051 findings across 61 rules; the `BASE-RUN-006` candidate is 2,109 across the same 61 rules. `npm run lint:quality` reproduces the inventory without making every PR red. Recommendation: burn the list down in correctness/architecture/mechanical phases and add `npm run lint:quality -- --strict` to required CI only when it reaches zero. See the [research](research/2026-08-06-abaplint-quality-roadmap.md) and [active plan](plans/abaplint-zero-findings.md). ## Open-issue orientation for the next phase diff --git a/docs/test-strategy.md b/docs/test-strategy.md index fb6fd98..c7bf8a8 100644 --- a/docs/test-strategy.md +++ b/docs/test-strategy.md @@ -4,7 +4,7 @@ This document defines the permanent test discipline for ZTOAD. The current basel ## Red–green–refactor through pull requests -`master` is the stable integration and release line. Each finding uses one short-lived branch and pull request; red states may exist locally or on the branch during development, but are never merged or pushed directly to `master`. The shared SAP native-abapGit repository remains linked to `master` for normal source-only work, so testing an unmerged source candidate must be recorded as a controlled direct deployment rather than a clean abapGit branch state. +`main` is the stable integration and release line. Each finding uses one short-lived branch and pull request; red states may exist locally or on the branch during development, but are never merged or pushed directly to `main`. The shared SAP native-abapGit repository remains linked to `main` for normal source-only work, so testing an unmerged source candidate must be recorded as a controlled direct deployment rather than a clean abapGit branch state. For every bug or feature: @@ -76,9 +76,9 @@ Do not use ports 50000 or 50001. Credentials stay in the ignored `.env` file and Run this sequence after deployment: -1. Confirm native abapGit points at the expected coordinated branch, refresh it, and review the complete system/Git diff. For normal source work this is `master`; a structural-object feature branch must be explicit in the evidence. +1. Confirm native abapGit points at the expected coordinated branch, refresh it, and review the complete system/Git diff. For normal source work this is `main`; a structural-object feature branch must be explicit in the evidence. 2. Confirm no unrelated inactive divergence and record the frozen candidate commit/source hash being tested. If unrelated drift exists, leave it unselected and list it; never use **Add All**. If source or serialized object content changes after this point, discard the affected evidence and restart deployment from this step. -3. Deploy and explicitly activate only the intended changed objects. Do not describe an unmerged directly deployed source as a native-abapGit `master` pull, and do not rely on a write request's activation option. +3. Deploy and explicitly activate only the intended changed objects. Do not describe an unmerged directly deployed source as a native-abapGit `main` pull, and do not rely on a write request's activation option. 4. Confirm active and inactive main source are identical, query inactive child parts for changed composite objects, then run active SAP syntax. Screens, GUI statuses, text elements, and includes must be checked separately; main-source equality does not clear an inactive child part. 5. Run all ABAP Unit tests; require zero failures. 6. Run the recorded ATC variants and inspect prerequisite/check errors. A result with missing prerequisites is incomplete even when no finding rows are displayed. @@ -86,7 +86,7 @@ Run this sequence after deployment: 8. Verify the installed dynpro and GUI status required by the scenario, then launch ZTOAD in a fresh browser session and run only a read-only sanitized smoke query, initially `SELECT SINGLE mandt FROM t000`. Enter the query with real user-like typing/paste and complete the editor's change/blur sequence; setting a DOM value programmatically is diagnostic only because SAP WebGUI may not transfer it to the backend control. If the SAP logon framework leaves the entire page non-interactive in the selected automation browser, do not repair or submit it through DOM mutation. When the user did not require that browser, use an authenticated supported browser session; otherwise record the UI gate as unavailable. 9. Verify the exact query reached execution through its expected UI/result state, then confirm ST22 has no dump newer than the captured marker. For an error-path smoke, a generic message proves safe presentation but not whether parsing, compilation, or runtime execution produced it; pair the smoke with a direct regression at the intended boundary and use a live fixture whose grammar is already proven on the target. Keep browser locators scoped to the query-editor control because ALV grid cells also expose textbox roles after a result renders. 10. Do not repeat the browser portion on NPL; repeat only the ADT activation/syntax/Unit/ATC gates there. -11. On a shared target, restore and explicitly activate the intended `master` object after evidence collection, then verify the relevant baseline tests and active/inactive state. Record an exception only when the maintainer reserves the deployed candidate for immediate follow-up work. +11. On a shared target, restore and explicitly activate the intended `main` object after evidence collection, then verify the relevant baseline tests and active/inactive state. Record an exception only when the maintainer reserves the deployed candidate for immediate follow-up work. If FLP cannot open WebGUI because the automation browser blocks a popup, record that environmental failure and use the standalone HTTPS WebGUI URL as a secondary diagnostic path. Before interpreting a runtime failure, verify that the installed report contains the serialized dynpros and GUI statuses required by the test. Classify missing installation metadata separately from a product-code regression, but keep the overall smoke gate blocked until both are green. diff --git a/scripts/repository-contract.mjs b/scripts/repository-contract.mjs index 7b973fa..64a4b40 100644 --- a/scripts/repository-contract.mjs +++ b/scripts/repository-contract.mjs @@ -4,6 +4,18 @@ import { strict as assert } from "node:assert"; const transactionPath = new URL("../src/ztoad.tran.xml", import.meta.url); const tablePath = new URL("../src/ztoad.tabl.xml", import.meta.url); const reportPath = new URL("../src/ztoad.prog.abap", import.meta.url); +const qualityWorkflowPath = new URL("../.github/workflows/quality.yml", import.meta.url); +const releaseWorkflowPath = new URL("../.github/workflows/release-please.yml", import.meta.url); + +const currentBranchGuidancePaths = [ + "../AGENTS.md", + "../CONTRIBUTING.md", + "../.github/pull_request_template.md", + "../docs/development.md", + "../docs/test-strategy.md", + "../docs/setup-evaluation.md", + "../docs/plans/abaplint-zero-findings.md", +]; let transactionXml; let tableXml; @@ -29,6 +41,18 @@ try { reportSource = await readFile(reportPath, "utf8"); +const [qualityWorkflow, releaseWorkflow] = await Promise.all([ + readFile(qualityWorkflowPath, "utf8"), + readFile(releaseWorkflowPath, "utf8"), +]); + +const currentBranchGuidance = await Promise.all( + currentBranchGuidancePaths.map(async (path) => ({ + path, + text: await readFile(new URL(path, import.meta.url), "utf8"), + })), +); + const expectedFragments = [ 'serializer="LCL_OBJECT_TRAN"', "ZTOAD", @@ -58,4 +82,34 @@ assert.ok( "Unsupported native SQL kernel call C_DB_EXECUTE must not exist in src/ztoad.prog.abap", ); -console.log("Repository contract passed: launcher, table, and forbidden-kernel-call checks are green."); +assert.match( + qualityWorkflow, + /push:\s*\n\s*branches:\s*\n\s*- main/m, + "Quality must run for pushes to the main branch", +); +assert.match( + releaseWorkflow, + /push:\s*\n\s*branches:\s*\n\s*- main/m, + "Release Please must run for pushes to the main branch", +); +assert.match( + releaseWorkflow, + /target-branch:\s*main/, + "Release Please must target the main branch explicitly", +); +assert.match( + releaseWorkflow, + /group:\s*release-please-main/, + "Release Please concurrency must use the main branch name", +); + +for (const { path, text } of currentBranchGuidance) { + assert.ok( + !/(?:`master`|refs\/heads\/master|origin\/master)/.test(text), + `${path} contains an obsolete operational master-branch reference`, + ); +} + +console.log( + "Repository contract passed: launcher, table, default-branch, and forbidden-kernel-call checks are green.", +); diff --git a/system-info.md b/system-info.md index 581a5e1..c9ddf31 100644 --- a/system-info.md +++ b/system-info.md @@ -31,7 +31,7 @@ _Updated: 2026-08-07_ · _Source: live ARC-1 discovery on A4H and NPL, native ab |---|---|---|---| | HANA | Yes | database | Database-specific paths can be tested, but tests must remain safe and sanitized | | RAP / CDS | Yes | ADT | Not used by the current classic report | -| abapGit | Yes | native, online | `ZABAPGIT` 1.133.0; ZTOAD repository key `000000000017`, package `ZTOAD`, verified on full ref `refs/heads/master` after the structural-object round trip | +| abapGit | Yes | native, online | `ZABAPGIT` 1.133.0; ZTOAD repository key `000000000017`, package `ZTOAD`, switched and freshly verified on full ref `refs/heads/main` after the GitHub default-branch migration; no pull was performed by the branch switch | | gCTS | Endpoint available | no ZTOAD repository | Native abapGit remains the selected round-trip mechanism | | Transports | Yes | CTS | Transportable package `ZTOAD`; active request `A4HK906379`, target `DEV`, layer `ZDEV` | | FLP / WebGUI | Yes | HTTPS | Serialized transaction `ZTOAD` resolves through both direct paths; exact `BASE-RUN-006` candidate proves the empty-editor/stream-input/ALV core mode and clean exit | @@ -48,7 +48,7 @@ The first request created during setup, `A4HK906377`, is an empty local request - **ARC-1 rule inventory**: 158 enabled, 25 disabled - **Repository gate**: pinned `@abaplint/cli` with the compatibility-focused rules in `abaplint.json` - **Compatibility floor**: SAP_BASIS 750; the separate 7.50 system is still required for the authoritative downport gate -- **Full quality inventory**: 2,109 findings across 61 rules on exact merged master `5218476`; 2,169 across 63 rules on BASE-BUG-002; diagnostic only until the zero-findings plan is complete +- **Full quality inventory**: 2,109 findings across 61 rules on exact merged default-branch checkpoint `5218476`; 2,169 across 63 rules on BASE-BUG-002; diagnostic only until the zero-findings plan is complete ## RAP Constraints Snapshot @@ -74,7 +74,7 @@ The first request created during setup, `A4HK906377`, is an empty local request | ATC `ABAP_CLOUD_READINESS` | Complete candidate run: 709 findings (490 P1, 219 P2); classic Dynpro/generated-program design is not ABAP Cloud compatible | | WebGUI smoke | Fresh real-input failure probe returned only the generic error; following read-only `T000` query returned three rows; complete 49-ID ST22 set unchanged | | Transaction launch | Standalone WebGUI and FLP `Shell-startGUI` intent both reach the complete ZTOAD transaction closure | -| Shared target after evidence | Restored and explicitly activated to `origin/master` `a5ad27c`; active/inactive server SHA-256 `202d9d40626428ab051a36de70180985da4e845a67e237d43e1036060db9ed4e`, 106/106 master Unit, no inactive ZTOAD part; native abapGit remained on `refs/heads/master` | +| Shared target after recorded BASE-RUN-002 evidence | Restored and explicitly activated to the then-default `origin/master` `a5ad27c`; active/inactive server SHA-256 `202d9d40626428ab051a36de70180985da4e845a67e237d43e1036060db9ed4e`, 106/106 baseline Unit, no inactive ZTOAD part. The GitHub branch was later renamed and native abapGit now selects `refs/heads/main`. | ## Coding Guidance @@ -96,9 +96,9 @@ The first request created during setup, `A4HK906377`, is an empty local request | Purpose | ADT-only minimum-release activation, syntax, ABAP Unit, ATC, and inactive-object gate | | ARC-1 | Separate `arc-1-750` profile, pinned to ARC-1 1.0.2; package ceiling configured as `*`; data preview and free SQL disabled | | UI boundary | No FLP, WebGUI, SAP GUI, or browser automation for validation; A4H owns UI smoke | -| ZTOAD state | Complete object set provisioned through native abapGit 1.134.0 offline repository in local package `$ZTOAD2`: PROG, real transparent TABL, TRAN, and SUSO | +| ZTOAD state | Complete object set provisioned through native abapGit 1.134.0 offline repository in local package `$ZTOAD2`: PROG, real transparent TABL, TRAN, and SUSO. Future reviewed offline ZIPs are generated from exact `origin/main`. | | Structural state | BASE-DDIC-001 candidate is active as `#NOT_EXTENSIBLE`; all seven table fields are unchanged and the offline serializer warning is resolved | -| Completion status | BASE-RUN-002 exact source candidate `92946fe`: syntax 0 errors, 109/109 Unit, complete `DEFAULT` ATC 85 findings (3 P1, 4 P2, 78 P3), and zero inactive ZTOAD parts; restored master is 106/106 with equal active/inactive source | +| Completion status | BASE-RUN-002 exact source candidate `92946fe`: syntax 0 errors, 109/109 Unit, complete `DEFAULT` ATC 85 findings (3 P1, 4 P2, 78 P3), and zero inactive ZTOAD parts; the restored then-default baseline is 106/106 with equal active/inactive source | | ARC-1 table-state caveat | Direct active `TABL` object-state returns 404 on this 7.50 endpoint; automatic and inactive-version reads resolve the active table and report no inactive draft. Explicit activation, exact metadata comparison, search, and the global inactive inventory are the compensating evidence. | See [the NPL ADT-only validation dossier](docs/research/2026-08-06-npl-adt-only-validation.md) and the [BASE-BUG-001 grammar investigation](docs/research/2026-08-07-base-bug-001-npl-count-grammar.md). No stub DDIC structure may be used to claim compatibility. From 7b15b3c612a2f44242ad27e3b003c5e3d5040a86 Mon Sep 17 00:00:00 2001 From: marianfoo <13335743+marianfoo@users.noreply.github.com> Date: Fri, 7 Aug 2026 18:30:57 +0200 Subject: [PATCH 2/2] docs: close default branch migration plan --- .../plans/{ => finished}/default-branch-main.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) rename docs/plans/{ => finished}/default-branch-main.md (79%) diff --git a/docs/plans/default-branch-main.md b/docs/plans/finished/default-branch-main.md similarity index 79% rename from docs/plans/default-branch-main.md rename to docs/plans/finished/default-branch-main.md index 17c35a8..c93f54b 100644 --- a/docs/plans/default-branch-main.md +++ b/docs/plans/finished/default-branch-main.md @@ -59,6 +59,21 @@ open release PR, or leaving local and native-abapGit clients on an obsolete ref. language," which describes localization rather than a Git branch. - SAP syntax, Unit, ATC, WebGUI, and ST22 are not applicable: no file under `src/`, no serialized SAP object, and no live behavior changed. +- Draft PR #34 targets `main`. First Quality run `31197841690` passed `npm ci`, + configured abaplint with zero findings, the default-branch repository + contract, and the installation contract; both external abaplint checks also + passed. +- The post-green audit reconciled all 15 changed files with the PR inventory, + reviewed the complete Quality log, found no review comments or unresolved + threads, and confirmed a clean merge state. GitHub still reports `main` as + default, remote `master` remains absent, and PR #23 remains based on `main`. +- The release PR's temporary `master` text is confined to its pre-migration + generated title/head branch. Release Please will be run from merged `main` to + update or replace that generated state; only one green release PR will be + retained. +- The useful durable improvements—the manual Quality dispatch and automated + default-branch contract—were already present in the first green head. No CI + correction was required. This plan is archived before the second CI run. ## Compatibility and risk review @@ -75,4 +90,4 @@ open release PR, or leaving local and native-abapGit clients on an obsolete ref. ## Reference -- [Migration research](../research/2026-08-07-default-branch-main-migration.md) +- [Migration research](../../research/2026-08-07-default-branch-main-migration.md)