docs: update WIMSE ECT draft; add -02 PDF; gitignore python artifacts

.gitignore

@@ -3,3 +3,8 @@
 draft-nennemann-wimse-ect-*.xml
 draft-nennemann-wimse-ect-*.txt
 draft-nennemann-wimse-ect-*.html
+
+# Python build/test artifacts
+__pycache__/
+*.egg-info/
+.coverage

draft-nennemann-wimse-ect.md

@@ -1768,6 +1768,129 @@ Trust Domain: internal.example
 ~~~
 {: #fig-internal title="Internal Microservice Workflow (L1)"}
 
+## Dev-SDLC (mixed L1-L3)
+{:numbered="false"}
+
+A software development lifecycle provides a canonical example of
+mixed assurance levels within a single continuous-delivery
+workflow.  A commit event triggers an internal build agent (L1),
+which produces a versioned artifact.  Three parallel agents then
+process the artifact: an LLM-powered code-review agent operated
+by an external vendor (L2, non-repudiation required), an SBOM
+and vulnerability scanner operated by a separate external scan
+vendor (L2), and an internal test runner (L1).  Their ECTs fan
+in to a staging deployment agent (L2) that operates across the
+organizational boundary of the artifact registry.  Once staging
+tests pass, a human approver issues an Authorization Context
+Token (ACT) via a Verifiable Credential, and the production
+deployment agent (L3) executes the promotion to the regulated
+production environment, recording its ECT on an audit ledger.
+A rollback agent (L3) uses the same ledger entry as its pred
+reference, ensuring the rollback is chained to the promotion it
+reverses.
+
+This workflow uses three assurance levels simultaneously because
+each phase carries different accountability requirements.
+Internal build and test steps (L1) do not cross trust boundaries
+and require no signing overhead.  Steps touching external
+vendors or the artifact registry boundary (L2) require signed
+ECTs so each party can prove its contribution non-repudiably.
+The production promotion and any rollback (L3) require tamper-
+evident audit-ledger entries to satisfy change-management and
+regulatory obligations (e.g., SOC 2, ISO 27001 change records).
+
+~~~
+Trust Domain: internal.example
+  Agent D1 (Build):
+    jti: task-301    pred:[]
+    iss: spiffe://internal.example/agent/build
+    exec_act: build_artifact
+
+  Agent D5 (Test Runner):
+    jti: task-303    pred:[task-301]
+    iss: spiffe://internal.example/agent/test
+    exec_act: run_tests
+
+Trust Domain: llm-vendor.example (external)
+  Agent D2 (LLM Code Review):
+    jti: task-302    pred:[task-301]
+    iss: spiffe://llm-vendor.example/agent/review
+    exec_act: llm_code_review
+
+Trust Domain: scan-vendor.example (external)
+  Agent D3 (SBOM/Vuln Scanner):
+    jti: task-304    pred:[task-301]
+    iss: spiffe://scan-vendor.example/agent/scanner
+    exec_act: scan_sbom_vulnerabilities
+
+Trust Domain: internal.example
+  Agent D4 (Staging Deploy):
+    jti: task-305    pred:[task-302, task-303, task-304]
+    iss: spiffe://internal.example/agent/staging
+    exec_act: deploy_staging
+
+  Agent D6 (Human Approver — ACT):
+    jti: task-306    pred:[task-305]
+    iss: spiffe://internal.example/identity/approver
+    exec_act: authorize_production_promotion
+
+  Agent D7 (Production Deploy):
+    jti: task-307    pred:[task-305]
+    iss: spiffe://internal.example/agent/prod-deploy
+    exec_act: promote_to_production
+
+  Agent D8 (Rollback):
+    jti: task-308    pred:[task-307]
+    iss: spiffe://internal.example/agent/rollback
+    exec_act: rollback_production
+~~~
+{: #fig-devsdlc title="Dev-SDLC Workflow (mixed L1-L3)"}
+
+The resulting DAG:
+
+~~~
+task-301 (build_artifact)  [internal.example, L1]
+   |            |                  |
+   v            v                  v
+task-302      task-303           task-304
+(llm_code_    (run_tests)        (scan_sbom_
+ review)       [internal,L1]      vulnerabilities)
+[llm-vendor,                     [scan-vendor,L2]
+ L2]                  \
+        \               \          /
+         \               v        /
+          +-----> task-305 (deploy_staging)
+                   [internal.example, L2]
+                          |
+                          v
+                   task-306 (authorize_production_promotion)
+                   [internal.example — human ACT]
+                          |
+                          v
+                   task-307 (promote_to_production)
+                   [internal.example, L3 — audit ledger]
+                          |
+                          v
+                   task-308 (rollback_production)
+                   [internal.example, L3 — audit ledger]
+~~~
+{: #fig-devsdlc-dag title="Dev-SDLC DAG"}
+
+Three properties distinguish this use case.  First, AI-
+intermediary ECTs from external vendors (task-302 from llm-
+vendor.example, task-304 from scan-vendor.example) are consumed
+as pred references by the internal staging deploy agent
+(task-305), demonstrating cross-domain fan-in where the
+internal orchestrator must verify externally-signed ECTs before
+proceeding.  Second, the human approver's ACT (task-306) is
+explicitly chained as a pred of the production deploy ECT
+(task-307), creating a verifiable record that promotion was
+authorized before execution — addressing the "what did the AI
+agent do to our production code?" audit requirement.  Third,
+the rollback ECT (task-308) chains to the promotion ECT
+(task-307), ensuring the audit ledger captures the full
+promote-then-rollback lifecycle as a single traceable unit.
+
 # Related Work
 {:numbered="false"}