Applying Copilot comment

Signed-off-by: Dominika Schweier <dominika.schweier@nokia.com>

Author: lovesprung

docs/content/en/docs/5_architecture_and_components/engine/design.md

@@ -53,8 +53,8 @@ This pattern ensures atomicity - either all changes succeed and are persisted, o
 ### Repository Abstraction
 
 The engine does not directly interact with Git repositories. Instead, it opens repositories through the **cache layer** and works with
-repository abstractions that hide storage implementation details. It also delegates all storage operations to repository adapters. And
-maintains separation between business logic and storage mechanisms.
+repository abstractions that hide storage implementation details. It also delegates all storage operations to repository adapters.
+Additionally, it maintains separation between business logic and storage mechanisms.
 
 ### Concurrency Model
 
@@ -119,7 +119,7 @@ The Engine exposes a single interface (`CaDEngine`) with operations grouped by r
 
 All operations are **context-aware** for cancellation and tracing. Operations accept **API objects** (porchapi types) and return
 **repository abstractions**. The interface is **synchronous**, which means that operations complete before returning. Additionally, errors
-are returned directly rather than stored in status fields
+are returned directly rather than stored in status fields.
 
 ## Package Lifecycle State Machine
 

docs/content/en/docs/5_architecture_and_components/engine/functionality/draft-commit-orchestration.md

@@ -394,7 +394,7 @@ the render status with function results is returned. This does not involve a lif
 The render is executed by running a configured KRM function pipeline. These functions can validate, transform and generate resources.
 The results are returned in RenderStatus.
 
-In case of render failure handling, the default behavior is to render errors to prevent draft closure (no resources persisted).
+In case of render failure, the default behavior is for render errors to prevent draft closure (no resources persisted).
 With the `porch.kpt.dev/push-on-render-failure: "true"` annotation, the draft is closed even on render failure. The behavior of
 partially-rendered resources can be further controlled via Kptfile annotations
 (see [kpt documentation](https://kpt.dev/book/04-using-functions/#debugging-render-failures)). The error is always returned to
@@ -491,8 +491,8 @@ It captures draft and repository references and logs a warning if a cleanup fail
 
 ### Rollback Limitations
 
-The rollback may fail if the repository connection is lost, during permission errors,
-when the draft is already closed, or when the repository in inconsistent state.
+The rollback may fail if the repository connection is lost, due to permission errors,
+if the draft is already closed, or if the repository is in an inconsistent state.
 
 In case of failure, the warning is logged with error details, but the original operation error is still returned.
 The draft may remain in the repository, which means that manual cleanup may be required. However, the repository
@@ -564,10 +564,10 @@ The Engine optimizes the draft-commit workflow:
 During lazy draft creation, a draft is created only when needed. Drafts are not created for metadata-only updates,
 or for read operations.
 
-Early validation is performed before draft creation. it fails fast without expensive operations
+Early validation is performed before draft creation. It fails fast without expensive operations
 and reduces rollback frequency.
 
-Another optimization is efficient draft closure, which uses single single repository operation,
+Another optimization is efficient draft closure, which uses single repository operation,
 atomic commit to Git and minimal overhead.
 
 ### Performance Characteristics

docs/content/en/docs/5_architecture_and_components/engine/functionality/lifecycle-management.md

@@ -485,13 +485,13 @@ Actual Deletion
 
 ### Tracking Benefits
 
-One of the benefits of tracking is compliance. It is visible who approved a package revisions for production,
-when package revisions were approved, and what changes were made.
+One benefit of tracking is compliance: it shows who approved package revisions for production, when they were approved,
+and what changes were made.
 
 Debugging is easier due to the package revision evolution history, the task execution sequence, and the lifecycle
 transition timeline.
 
 With rollback, previous stable versions can be identified. It is easier to understand changes between versions, and
 possible to revert to known-good states.
 
-Finally, governance, enforce approval workflows. Package revision modifications are audited and package lineage is tracked.
+Finally, governance is improved by enforcing approval workflows, auditing package revision modifications, and tracking package lineage.

docs/content/en/docs/5_architecture_and_components/engine/functionality/task-coordination.md

@@ -209,7 +209,7 @@ Compare Task Lists
   Apply New Tasks
 ```
 
-**Comparison logic:** Tasks are append-only (never removed) and task list lengths are compared.. New tasks are those
+**Comparison logic:** Tasks are append-only (never removed) and task list lengths are compared. New tasks are those
 beyond old list length. New tasks are applied in order.
 
 **Task application:** Each new task is executed sequentially. The Draft is modified by each task. In case of an error,
@@ -261,7 +261,7 @@ PackageRevision is the current package revision from the repository, which provi
 It contains the function pipeline configuration.
 
 Draft is a mutable workspace for modifications. The resources are updated directly and it is modified by
-new tasks.
+resource mutations (including the render task).
 
 Old PackageRevisionResources is the previous resource content, which is used for comparison (not currently used).
 It has an audit trail.
@@ -395,8 +395,8 @@ Task List: [init/clone/edit/upgrade]
   Return Success
 ```
 
-Tasks are executed sequentially. This means, that typically one task init, clone, edit, or upgrade) is executed at the time
-and ach task must succeed before the next. The first error stops the execution. No parallel task execution is allowed.
+Tasks are executed sequentially. This means that typically one task (init, clone, edit, or upgrade) is executed at a time,
+and each task must succeed before the next. The first error stops execution. No parallel task execution is allowed.
 
 This is needed because tasks may depend on previous tasks. This way, error handling is simplified and consistent state
 is maintained.
@@ -451,8 +451,8 @@ The Engine interacts with Task Handler through a defined interface:
 
 ### Interface Characteristics
 
-The interface is context-aware. All methods accept context for cancellation Timeout and deadline is supported.
-Tracing and logging context.
+The interface is context-aware. All methods accept context for cancellation. Timeout and deadline is supported.
+Tracing and logging context is propagated as well.
 
 It is draft-based, meaning that all methods work with draft workspaces and no direct repository modification
 is performed. Includes isolation and atomicity.
@@ -471,7 +471,7 @@ enforces business rules.
 The Task Handler implements task logic, transforms package content, executes functions, and
 returns results.
 
-The benefit of this separation is that both component has clear responsibilities. Testing and maintenance is easier, and
+The benefit of this separation is that both component have clear responsibilities. Testing and maintenance are easier, and
 pluggable task implementations can be applied. Additionally, evolution of the components is independent.
 
 ### Extensibility

docs/content/en/docs/5_architecture_and_components/engine/functionality/validation-business-rules.md

@@ -77,8 +77,8 @@ CreatePackageRevision
 
 **Rationale:**
 
-The packages must progress through Draft/Proposed states before being published. This prevents the bypassing of the review/approval
-workflows. This way all packages have a draft history.
+Packages must progress through the Draft/Proposed states before being published. This prevents bypassing the review/approval
+workflows and ensures all packages have a draft history.
 
 ### Update Lifecycle Validation
 
@@ -146,7 +146,7 @@ CreatePackageRevision
 **Rationale:**
 
 Only allowing one operation simplifies the creation workflow. However, you can add multiple tasks later with updates. The default init
-task provides sensible starting point.
+task provides s sensible starting point.
 
 ### Task Type Validation
 
@@ -397,7 +397,7 @@ Upgrade Task Validation
 **Rationale:**
 
 Upgrade performs a three-way merge (old upstream, new upstream, local). Source revisions must be stable (published) for reliable merge.
-This prevents upgrading from unstable draft versions
+This prevents upgrading from unstable draft versions.
 
 ### Upgrade Source Requirements
 

docs/content/en/docs/5_architecture_and_components/engine/interactions.md

@@ -65,7 +65,7 @@ The engine never directly manipulates Git repositories or storage - all operatio
 
 ### Cache Invalidation
 
-The engine does not directly invalidate cache entries. Instead, the cache monitors Repository CRs for changes, and cackground sync jobs refresh
+The engine does not directly invalidate cache entries. Instead, the cache monitors Repository CRs for changes, and background sync jobs refresh
 repository state periodically. Repository operations (create, update, delete) trigger cache updates automatically. Engine operations are always
 performed on the latest cached state.
 
@@ -146,8 +146,8 @@ Update resources + render
 4. Task handler executes render task (runs function pipeline)
 5. Returns render status with function results
 
-The Engine provides the draft workspace, the Task handler modifies resources in the draft, after which the Engine commits
-the draft after task completion. The Task handler has no direct repository access.
+The Engine provides the draft workspace. The Task handler modifies resources in the draft, after which the Engine commits
+the draft. The Task handler has no direct repository access.
 
 ### Function Runtime Integration
 
@@ -254,8 +254,8 @@ API Server Watch Streams
 - **Modified**: Package revision updated (metadata or lifecycle)
 - **Deleted**: Package revision removed
 
-Notifications are sent after successful package revision creation,  after package revision updates (including lifecycle transitions),
-and after metadata-only updates on published packages. Notification are not sent on failures or during draft operations.
+Notifications are sent after successful package revision creation, after package revision updates (including lifecycle transitions),
+and after metadata-only updates on published packages. Notifications are not sent on failures or during draft operations.
 
 ### Watch Stream Support