SDK-4673 update documentation

docs/scu/dev/features/autointegration-of-spryker-module-releases.md

@@ -6,32 +6,38 @@ template: concept-topic-template
 
 # Challenges of integrating Spryker Code Releases
 
-Spryker architecture requires to connect functionalities of different modules in your project code by using the defined extention points. Spryker Code Upgrader automatically integrates Plugins, sets configurations keys, adds new translations etc to your project code. This results in removing the manual step when your engineer needs to understand and apply code changes to activate the new feature in your project.
-
-Explain supported extention points:
-- Configurations (find links)
-    default php
-    module config
-- Plugin stacks (find links)
-- Translations (find links)
-- XML
-- ???
+Spryker architecture provides extensibility of different modules by using extension points in the project code.
+With Spryker Code Upgrader, the process of integrating plugins, configuration updates, adding new translations, and other code changes is automated.
+As the result the manual step can be skipped when engineers have to understand and apply code changes by themselves in order to add new features in the project.
+
+Supported extension points:
+- Configure
+  - module
+  - environment
+- Copy module files
+- Add/Remove
+  - plugin
+  - navigation
+  - widget
+  - glue relationship
+- Add
+  - transfer
+  - db schema
+
+# What is release rating
+The release rating is a measure of the integrability coverage of each spryker release, representing the percentage of integrated plugins, configurations, schemas, and other components.
+This rating is determined through internal testing, where the updated code is compared with the released code to assess the level of integration achieved.
+
+There are some kind of releases that provide only dependency updates without any code integrations (so called module-only releases). Such releases have 100% coverage. 
+
+The rating for each applied release can be found in the upgrader pull request description.
 
 # How to enable and configure
+By default, the Integrator is enabled. It applies integrations of releases that have rating of more than 70% (this threshold can be configured through the spryker CI configuration).
 
-- enabled by default
-- not all the releases are integrated, but those having high integratability coverage
-- code is process by code style fixers, ensure you have it in your project
-
- How Upgrader decides what release to integrate?
-- each release has an integrability coverage which is from 0 to 100%, Upgrader integrates those releases having 70+% but it can be changed by self-service.
-
-# What is integrability coverage
-- internally Spryker tests how the release can be integrated and what plugins, configuration etc need to change in your project code the coverage shows the number of those changes that can be replayed automatically
-- there are some releases that do not need any integrations (so called module-only releases), these receive 100% coverage. Explain what module-only means or find a better name
-- you can see the coverage of each release in the PR that is created by Spryker Code Upgrader
+It is important to note that after the integration process is completed, a style fixer is applied to the updated files. It's recommended for the project to have its own style fixer to expose project-specific code style conventions.
 
 # What to do if you see a generated code, that is not valid
-1. Ensure that your project code is passing Upgradability Guidelines and Evaluator check (links)
-2. Quick fix might be to manually correct the generated code
-3. If none of those help, please contact us
+1. Make sure that your project code follows the Upgradability Guidelines and passes the [Evaluator check](/docs/scos/dev/guidelines/keeping-a-project-upgradable/run-the-evaluator-tool.html).
+2. You can try manually updating the generated code as a quick fix.
+3. If none of the above solutions work, please contact us for further assistance.

docs/scu/dev/features/security-upgrades.md

@@ -4,34 +4,48 @@ description: How Spryker Code Upgrader works with releases related to known secu
 template: concept-topic-template
 ---
 
-Receive security releases before any other releases offered to you by Spryker Code Upgrader, ensuring the timely application of critical security fixes. And run static code analsys tools to detect other known vulnerabilities.
+TBD: Generic Description
 
 # What kind of security releases covered?
 
-Spryker Code Upgrader service helps you with vulnerabilities form these three sources:
+The static code analysis tools provide the capability to detect various known vulnerabilities.
+
+These tools assist in identifying and preventing potential security risks from these sources:
 1. Spryker Security releases
 2. PHP Ecosystem
 3. NPM Ecosystem
 
 ## Spryker Security releases
 
-1. What is that.
-Example of a security release in the release app. Screenshot?
-2. How to receive them as an upgrade via SCU
-- emphasise the prio of security releases vs others
-- explain that it works between majors
-- explain that major upgrade will need to be done manually
-3. How to detect vulnerabilities via Evaluator -> link to respective evaluator pages
--  How it works under the hood internally etc.
+Security release is a type of release that aims to deliver a security vulnerability fixes, rather than introducing new features or functionalities.
+The example of security release is [https://api.release.spryker.com/release-group/4753](https://api.release.spryker.com/release-group/4753)
+
+The security releases are applied alongside other releases, but the security release being prioritized and delivered first, ensuring the fast delivery of critical security updates.
+
+Automatic installation of security releases is only available between the major version releases. However, the major releases require manual installation, similar to all major releases.
+
+[Evaluator analysis tool](/docs/scos/dev/guidelines/keeping-a-project-upgradable/run-the-evaluator-tool.html) can be used to detect if there are any security fixes available for the Spryker modules in your project.
+It has the corresponding [Spryker security checker](docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.md) for that.
 
 ## PHP Ecosystem
-1. What is that.
-2. How to detect vulnerabilities via Evaluator -> link to respective evaluator pages
--  How it works under the hood internally etc.
+The PHP ecosystem refers to everything related to the PHP code, which includes the Spryker PHP conventions and rules.
+
+To detect violations related to it [Evaluator analysis tool](/docs/scos/dev/guidelines/keeping-a-project-upgradable/run-the-evaluator-tool.html) can be used.
+
+The Evaluator checkers responsible for that:
+- [Additional logic in dependency provider checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/additional-logic-in-dependency-provider.html)
+- [Container set function checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/container-set-function.html)
+- [Dead code checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/dead-code-checker.html)
+- [Minimum allowed shop version checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/minimum-allowed-shop-version.html)
+- [Multidimensional array checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/multidimensional-array.html)
+- [Open-source vulnerabilities checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/open-source-vulnerabilities.html)
+- [PHP versions checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/php-version.html)
+- [Plugin registration with restrictions checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/plugin-registration-with-restrintions.html)
+- [Single plugin argument checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/single-plugin-argument.html)
+- [Spryker dev packages checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-dev-packages-checker.html)
+- [Upgradability guidelines checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/upgradability-guidelines.html)
 
 ## NPM Ecosystem
-1. What is that.
-2. How to detect vulnerabilities via Evaluator -> link to respective evaluator pages
-- How it works under the hood internally etc.
-- Explain critical vs info etc on the evaluator pages
+The NPM ecosystem refers to everything related to the packages and tools available through the NPM.
 
+NPM violations can be detected by [Evaluator analysis tool](/docs/scos/dev/guidelines/keeping-a-project-upgradable/run-the-evaluator-tool.html) with the corresponding [NPM checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/npm-checker.html) for that.

docs/scu/dev/features/upgrade-verification.md

@@ -6,16 +6,25 @@ template: concept-topic-template
 
 It is very important for Spryker Code Upgrader to ensure stability of the upgrades. On the one hand you have your automated tests that you rely on, those tests are run in your CI system and you use them before you merge the pull requested created by Spryker Code Upgrader. On the other hand and in addition we run a number of code checks to offer an early warning system even without having a full context or knowledge of your project.
 
-# What kind of validations we run?
+# Validations and warnings
 
-- Major code releases
-- PHP Broken Files (phpstan)
-- Conflict between your class that extended a private class in a Spryker module and when Spryker changed their class in the release
-- Module name conflict checker
-- Release integration warnings
-- Upgrader warnings
+The upgrader offers validations ensure the accuracy and safety of the upgrade process.
+The warnings provide guidance on potential risks or necessary actions for a successful upgrade.
+
+Warning types:
+- Major code releases warning.
+  All the major releases should be installed manually to avoid the BC breaks.
+- PHP Broken Files. 
+  Phpstan checks project code after each release application and provides corresponding warnings.
+- Conflict between project class, which extends a private class in a Spryker module, and a changes made by Spryker in their latest release.
+  To resolve this conflict need to re-write custom class with the necessary updates.
+- Module name conflict warnings.
+  Custom project module has the same name with spryker released module and should be renamed.
+- Release integration warnings (warnings related to the integration process)
+- Upgrader warnings (warnings related to the upgrader process)
 
 # What to do when you see these warnings in the PR?
 
-Generic explanation about how to check a file in PHP Storm -> fix the file, rename module or class, recheck the inherited class to be compatible with the base one.
+In most cases, warnings come with specific information that helps you identify the class or file needed to fix the issue.
+Most of these issues are easily fixable by an IDE.