Docs - Minor Fixes in Porch Engine (kptdev#446)

* clarify task list contains single task and fix lifecycle validation

Signed-off-by: aravind.est <aravindhan.a@est.tech>

* Fix review comments

Signed-off-by: aravind.est <aravindhan.a@est.tech>

---------

Signed-off-by: aravind.est <aravindhan.a@est.tech>

Author: aravindtga

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

@@ -134,17 +134,17 @@ CreatePackageRevision
         │
         No
         ↓
-  Draft/Proposed? ──Yes──> Allow
+  Draft? ──Yes──> Allow
         │
         No
         ↓
-  Published/DeletionProposed? ──Yes──> Reject
+  Proposed/Published/DeletionProposed? ──Yes──> Reject
 ```
 
 **Process:**
 1. **Empty lifecycle**: Defaults to Draft
-2. **Draft or Proposed**: Allowed for creation
-3. **Published or DeletionProposed**: Rejected with error
+2. **Draft**: Allowed for creation
+3. **Proposed or Published or DeletionProposed**: Rejected with error
 4. **Invalid value**: Rejected with error
 
 **Update validation:**
@@ -313,7 +313,7 @@ CreatePackageRevision
         │
         No
         ↓
-  Draft/Proposed? ──Yes──> Continue
+  Draft? ──Yes──> Continue
         │
         No
         ↓
@@ -337,11 +337,11 @@ UpdatePackageRevision
         ↓
   Check Current Lifecycle
         ↓
-  Draft/Proposed? ──Yes──> Full Update Path
+  Draft? ──Yes──> Full Update Path
         │
         No
         ↓
-  Published/DeletionProposed? ──Yes──> Metadata Only Path
+  Proposed/Published/DeletionProposed? ──Yes──> Metadata Only Path
         │
         No
         ↓
@@ -457,10 +457,7 @@ The lifecycle system maintains an audit trail of package revision evolution:
 - Used for tracking approval timing
 
 **Tasks:**
-- Append-only list of operations performed
-- Each task represents a modification
-- First task indicates creation method (init, clone, edit, upgrade)
-- Subsequent tasks show evolution history
+- Typically contains a single task indicating creation method (init, clone, edit, upgrade)
 - Stored in PackageRevision spec
 
 **Resource Version:**

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

@@ -431,24 +431,12 @@ ApplyTask/DoPRMutations/DoPRResourceMutations
 
 The Engine uses specific patterns for task coordination:
 
-### Sequential Task Execution
+### Task Execution
 
 ```
-Task List: [init, clone, render]
+Task List: [init/clone/edit/upgrade]
         ↓
-  Execute init
-        ↓
-  Success? ──No──> Return Error
-        │
-       Yes
-        ↓
-  Execute clone
-        ↓
-  Success? ──No──> Return Error
-        │
-       Yes
-        ↓
-  Execute render
+  Execute [init/clone/edit/upgrade]
         ↓
   Success? ──No──> Return Error
         │
@@ -458,7 +446,7 @@ Task List: [init, clone, render]
 ```
 
 **Sequential execution:**
-- Tasks executed in order
+- Typically one task (init, clone, edit, or upgrade)
 - Each task must succeed before next
 - First error stops execution
 - No parallel task execution
@@ -468,26 +456,19 @@ Task List: [init, clone, render]
 - Simplifies error handling
 - Maintains consistent state
 
-### Append-Only Task List
+### Task List Pattern
 
 ```
 Create: [init]
         ↓
-Update: [init, clone]
+Update: [clone/edit/upgrade]
         ↓
-Update: [init, clone, render]
+Update: [render]
 ```
 
-**Append-only pattern:**
-- Tasks never removed from list
-- New tasks appended to end
-- Task history preserved
-- Audit trail of operations
-
-**Benefits:**
-- Clear operation history
-- Reproducible package state
-- Debugging and troubleshooting
+**Task list pattern:**
+- Single persistent task indicating [init/clone/edit/upgrade] method
+- Task history shows package origin
 
 ### Draft Isolation
 

docs/content/en/docs/5_architecture_and_components/porch-apiserver/_index.md

@@ -10,7 +10,7 @@ description: |
 
 The **Porch API Server** is a Kubernetes extension API server that exposes Porch's aggregated API resources (PackageRevision, PackageRevisionResources, Package) and CRDs (Repository, PackageRev) through the Kubernetes API. It acts as the entry point for client interactions with Porch, translating Kubernetes API requests into operations on the underlying Engine and Cache.
 
-> The PackageVaraint and PackageVariantSet CRDs are not controlled by the Porch API server. They are controlled by the [Porch Controllers]({{% relref "/docs/5_architecture_and_components/controllers/_index.md" %}})
+> The PackageVariant and PackageVariantSet CRDs are not controlled by the Porch API server. They are controlled by the [Porch Controllers]({{% relref "/docs/5_architecture_and_components/controllers/_index.md" %}})
 
 The Porch API Server is responsible for: