Many objects. Several developers, each on their own machine. Months of work, and a board that wants to know where it stands. These are the eight steps, what CSPeach does at each one, and — plainly — what is built today.
The programme, step by step
Eight steps, in the order they happen. Each one says what is built today, and where something is still planned it says that too.
Start from what the system says exists. cspeach team discover
reads the system inventory: the packages, the custom code objects, the
changes to SAP's own objects, and how long the system has recorded usage.
Not a spreadsheet someone kept: the system's own answer.
/abap-cca reads that inventory and proposes the scope: packages in, out, or to ask about, and candidates to retire. It runs no check and writes no files. The lead decides what is in.
The lead starts the project in a folder the team already shares, such as
OneDrive, and adds the people. The lead picks the ATC check variant.
SAP's own ABAP_CLOUD_READINESS is offered first, and CSPeach
checks the system has it. The lead picks one transport request for the project,
and every write card names it.
The packages split into lanes, balanced by the work, one person to each lane. The lead can move a package to someone else, with a reason.
SAP's own check — ATC — runs over the whole scope with the check variant the lead picked. Out comes the list: what breaks the rules, where, how badly. Nobody opens programs one by one to find problems; the system's check finds them.
If the check runs on a central system, CSPeach reads its export file instead.
SAP's clean-core check stays silent about clean objects when the same run finds anything. CSPeach never takes silence for clean — an object it has heard nothing about is shown as “not measured”.
So we ran the silent 15 again on their own. SAP listed all 15 with no findings, in under five seconds. Clean.
The 775 are not one kind of work. About one in four is fix: read a released view instead of an SAP table, use a released type. About three in four is decide: a classic report with list output, selection screens or ALV does not get fixed into ABAP Cloud, so someone decides to keep it at its level, retire it or rebuild it. That is step 4, and it is why management signs it off.
SAP's own checks, in SAP's words: Usage of Released APIs 425 · ABAP Language Version 320 · object types not allowed in cloud development 16 · other 14. By priority: 722 · 39 · 14. The rule set is ABAP_CLOUD_READINESS, a standard check variant on the system, not ours.
Each person triages their own rows. CSPeach proposes what happens to each object — keep, fix, retire or rebuild — and a level, A to D, with the evidence behind it. The card says plainly that it is a proposal:
Record CLAS ZCL_MM_EQUIP as proposed: fix, level C, no target set?
Proposed reason: uses 1 not-released application API; swap it for a released successor
Matches your rule: a small class using unreleased or deprecated APIs: swap to released ones
Every decision says whose words they are. A proposal stays marked “proposed”. A person's own reason reads as theirs. When two people disagree, the lead's ruling settles it, and the History shows it as a ruling.
The lead can set a target level for the whole project or for one object. With no target, CSPeach says “no target set”.
Approval-gated is the default write mode. Each fix waits behind a card that shows what changes in behaviour, the transport, the risk and why it was raised, and the method diff. The person approves each write.
Change class ZCL_MM_EQUIP
Behaviour: Same fields and rows from the same table, but I_Equipment applies SAP's equipment access control …
Package ZMM_STOCK · Transport: S4HK903753 (object already locked here)
Risk: medium (raised: activation makes the change live on the system)
[a] Approve [d] Show diff [s] Skip [c] Cancel turn
A snapshot comes first, then the write, the syntax check and activation. The hard ones — modifications, internal SAP objects with no successor — get a design before anyone touches them.
A fix counts only when SAP's own check proves it. After the write, the object reads “fixed, awaiting check”. When the team check runs again, it reads “fix proven”, or “fix failed the check”. A developer's word starts the clock; the check stops it.
The fix card, and the road to proof
One set of numbers, everywhere. Management reads the status page and the Excel workbook: Summary, Objects, For the business, and History. The terminal status, the status page and the workbook show the same counts, and the CSV export carries every object row behind them.
Nobody fills anything in. The files are written into the shared folder as the work happens, and the status page is read-only.
After go-live, new code goes in clean: the approach and the level are decided before the build, and every write is syntax-checked before it is activated. Cleaning up the old code is a project with an end. Keeping new code clean has no end — it is how every change is built from then on.
Built is in the product today. Planned is what we're building next — no date yet.
Run live with two people
We ran a clean-core project on a live S/4HANA system with two people in one shared folder. This is how the work moved, in the words CSPeach printed.
Every decision keeps whose words it is. A proposal stays marked “proposed”. A person's reason stays theirs. When two people disagree, the lead's ruling settles it, and the History sheet shows it as a ruling.
Proof
Each fix waits behind a card, and the person approves the write. Then it waits for the team check. On the live run two people wrote three fixes to SAP, and SAP's own ATC check proved each one.
After the write, the object reads “fixed, awaiting check”. Only
the team check, cspeach team refresh, moves it on.
What management reads
The terminal status, the status page and the Excel workbook show the same counts, and the parts add up. The CSV export carries every object row behind them.
Three seats
Nobody fills in a status. The files are written as the work happens.
Skill by skill
Recommends the clean-core approach for a requirement or an object, and classifies the clean-core level A, B, C or D — with citable evidence to defend the call.
When CSPeach is connected, it verifies that against your live system: released-API state and ATC.
Read-onlyChecks ABAP code for clean core and cloud readiness — unreleased APIs, classic statements, direct access to SAP standard tables, and statements not allowed in ABAP Cloud.
Each finding comes with concrete modernization guidance.
Read-onlyJudgement over the inventory the lead already pulled with
cspeach team discover: the scope (packages in, out, or to
ask about), an application area for packages without one, and retire
candidates with their evidence. Retire stays a candidate until your
lead confirms it.
It runs no ATC and no SQL, and writes no files. It ends with the exact team commands to run next.
Read-onlyBuilds a complete RAP stack — database table, CDS interface view, CDS projection view, behavior definition, behavior implementation, metadata extension, service definition, service binding — created and activated on your system in dependency order, after a plan your developer approves.
On a model that already exists, /abap-extend-model adds a
field, a UI column, a validation, a determination or an action in place,
and /abap-eml writes and tests the EML.
/abap-upgrade-scan runs the ATC readiness scan.
/abap-upgrade-fix works through the findings with
successor-API lookup, a syntax check before every write, and snapshot
rollback if one goes wrong.
/abap-upgrade-verify writes the sign-off report.
Extends SAP-delivered standard through BAdIs, enhancement spots and exits.
It explains the trade-offs between them before anything is chosen.
Moves a classic program to the best modern architecture your release supports — RAP, SEGW or OO.
Which one it proposes depends on the release you are on.
Where the knowledge comes from
Each skill carries written rules for RAP, CDS and ABAP Cloud — naming, the order objects must be created and activated in, type codes, annotations, draft handling, access control. Those rules were learned on live S/4HANA systems, and they are part of the skill.
Then the result is checked on your own system. Nothing is called done because it looked right.
CSPeach proposes.
Your system decides.
RAP and CDS
This is what /abap-rap creates, and the order it creates it in.
Created and activated on your system in dependency order, after a plan your developer approves.
Works where you are
ECC EHP7+, on-premise S/4HANA, and S/4HANA Cloud Private Edition. The clean-core work starts on the system the customer has today — there is no move to make first.
CSPeach is read-only by default, and approval-gated is the default write mode. Each write is snapshotted, syntax-checked, activated and verified. A session writes to the session's transport, but an object SAP already holds in a request stays in that request, and the card says so. In a team project, the lead picks one request at the start, and every write card names the request it goes to. The gates are written out on the trust page.
Questions
No — SAP's own check does. ATC runs over the scope you choose with the rule set you choose, and the findings are SAP's: what breaks the rules, where, and how badly. CSPeach runs that check, or reads its export, and turns what comes back into the project's picture. Nobody opens programs one by one to go looking. Measured on a live S/4HANA system with SAP's ABAP Cloud readiness rule set, on our own test package: 43 objects asked about, 28 with findings, 15 clean, 775 findings in 19 seconds. SAP's clean-core check stays silent about clean objects when the same run finds anything, so we ran the silent 15 again on their own and SAP listed all 15 with no findings. CSPeach never takes silence for clean.
Then CSPeach reads its export instead of running the check itself. cspeach team refresh --from-file takes the ATC result file your central system produces and measures the project against it, exactly as it would a run of its own.
As many as you have. The packages split into lanes, balanced by the work, and each developer takes a lane. Everyone works on their own machine and writes into a folder your team already shares — one writer per file, so nothing is overwritten and nobody waits for anybody. The lead can move a package between people, with a reason. We ran it live with two people.
The status page and the Excel workbook, with its Summary, Objects, For the business and History sheets. They show the same counts as the terminal status, and the CSV export carries every object row behind them: every object in scope, who owns it, what was decided and in whose words, and what SAP's check has proven. Nobody fills anything in. Team projects are new — ask us for access.
Two things, named plainly. A wave sign-off. And ATC and the released-API check after every write — today a write gets a syntax check, then activation and a check that the object really went active. CSPeach does not block a transport; that gate, if you want one, belongs to your release process.
No. CSPeach is a development agent: it works in your development system. Changes reach production the way they always have — through the transports and the release process you already run. Three write modes ship, and approval-gated is the default, so by default a developer says yes to each write.
Yes. /abap-clean-core recommends the clean-core approach for a requirement or an object and classifies the clean-core level A, B, C or D, with citable evidence to defend the call. /abap-cloud-check checks ABAP code for unreleased APIs, classic statements, direct access to SAP standard tables and statements not allowed in ABAP Cloud. /abap-cca reads the estate inventory from cspeach team discover and gives judgement: the scope, application areas and retire candidates. It runs no ATC and no SQL, and writes no files.
Each skill carries written rules for RAP, CDS and ABAP Cloud — naming, the order objects must be created and activated in, type codes, annotations, draft handling and access control — learned on live S/4HANA systems. /abap-rap builds the whole stack: database table, CDS interface view, CDS projection view, behavior definition, behavior implementation, metadata extension, service definition and service binding. /abap-extend-model changes an existing CDS view or RAP business object in place, and /abap-eml writes and tests the EML.
Yes, on your own system. /abap-cloud-check reports the unreleased APIs a custom object uses, and /abap-clean-core verifies its classification against the live released-API state and ATC when CSPeach is connected. The upgrade skills look up successor APIs for what has to be replaced.
Yes. CSPeach runs against ECC EHP7 and above, on-premise S/4HANA, and S/4HANA Cloud Private Edition. The clean-core work starts on the system you have today.
They do different jobs. CSPeach does the clean-core work described on this page, on ECC, on-premise S/4HANA and S/4HANA Cloud Private Edition. The side-by-side page sets out what each one is for.