Compare commits

...
Author SHA1 Message Date
jarvis-at-skic 65e546c448 refactor: implement governed Delivery program contracts 2026-10-23 06:39:27 +00:00
jarvis-at-skic c306ea4794 Merge pull request 'refactor: implement bounded Delivery existing-owner simplification' (#13) from refactor/delivery-existing-owners into test 2026-10-22 22:16:23 -07:00
jarvis-at-skic de2e201c4e refactor: simplify Delivery through existing procedure owners 2026-10-23 05:12:21 +00:00
jarvis-at-skic 225ae3b068 Merge pull request 'docs: canonical SKIC channel skill naming' (#12) from docs/canonical-skic-reference-names into test 2026-10-21 10:58:12 -07:00
jarvis-at-skic 5068145048 docs: reconcile canonical SKIC channel skill names 2026-10-21 17:56:57 +00:00
jarvis-at-skic b45dc2d833 Merge pull request 'docs: promote reusable AeroSim channel lessons' (#11) from docs/aerosim-reference-lessons-20261020 into test 2026-10-20 11:42:59 -07:00
jarvis-at-skic 5a0949658d docs: promote reusable AeroSim channel lessons 2026-10-20 18:42:39 +00:00
jarvis-at-skic 0bf71b905f Merge pull request 'policy: retain artifact validation in Delivery' (#10) from policy/artifact-validation-boundary into test 2026-09-26 05:15:23 -07:00
jarvis-at-skic 36ae5f50e4 policy: retain artifact validation in Delivery 2026-09-26 12:02:14 +00:00
jarvis-at-skic 5ead0aeabf Merge pull request 'policy: limit Delivery to unit testing' (#9) from policy/unit-tests-only into test 2026-09-26 03:35:30 -07:00
jarvis-at-skic 44e6aa5db6 policy: limit Delivery to unit testing 2026-09-26 10:10:52 +00:00
jarvis-at-skic c61c517aa0 docs: route Delivery through reusable development skills
Validated development-skill routing and reference corrections.
2026-09-23 12:49:39 -07:00
jarvis-at-skic d185f9b2d6 docs: clarify development skill precedence 2026-09-23 19:45:36 +00:00
jarvis-at-skic 6190262538 docs: route Delivery through development skills 2026-09-23 19:38:14 +00:00
jarvis-at-skic 52bee5e227 docs: require direct Hermes Kanban links 2026-09-23 19:04:57 +00:00
jarvis-at-skic c32f8c998d feat: mine reusable AeroSim channel lessons 2026-09-10 11:41:46 +00:00
jarvis-at-skic 2535089fdd Merge immediate wave-start visibility policy
Require a dedicated pushed branch and visible PR for each Task before substantive wave implementation.
2026-09-07 03:09:22 -07:00
jarvis-at-skic 573b79ae79 docs: require immediate task branches and PRs 2026-09-07 10:08:43 +00:00
jarvis-at-skic c9d4768cd2 chore: open delivery-start visibility change 2026-09-07 10:03:24 +00:00
jarvis-at-skic 6aaed69294 Merge pull request 'Clarify READY_FOR_DELIVERY handoff semantics' (#6) from fix/ready-for-delivery-handoff into test 2026-09-07 02:30:19 -07:00
jarvis-at-skic 1309b2726c docs: clarify READY_FOR_DELIVERY handoff 2026-09-07 08:53:32 +00:00
jarvis-at-skic 40afd90e08 Merge pull request #5 from fix/canonical-scope-status-vocabulary
fix: enforce canonical Scope status vocabulary
2026-09-07 01:40:02 -07:00
jarvis-at-skic ecfd588348 fix: enforce canonical scope status vocabulary 2026-09-07 08:26:24 +00:00
jarvis-at-skic d63fcb39c0 Merge pull request 'Standardize per-project reusable CI base images' (#4) from docs/base-image-ci-strategy into test 2026-09-06 08:02:10 -07:00
jarvis-at-skic 2815fdd4b3 docs: standardize project CI base images 2026-09-06 14:57:51 +00:00
jarvis-at-skic 74cbc689ea Merge pull request 'fix: make storage procedure discovery fail closed' (#3) from fix/storage-procedure-safety into test 2026-09-05 07:27:43 -07:00
jarvis-at-skic c44c140fcd fix: make storage procedure discovery fail closed 2026-09-05 14:27:42 +00:00
jarvis-at-skic 78c6218bd1 Merge pull request 'policy: place runtime resources on shared platforms' (#2) from policy/runtime-resources-on-platform into test 2026-09-05 07:22:16 -07:00
jarvis-at-skic 611809d5d7 policy: place runtime resources on shared platforms 2026-09-05 14:22:15 +00:00
jarvis-at-skic 9edfbba511 fix: update Corp v1 skill references 2026-09-04 12:55:02 +00:00
jarvis-at-skic 20cb78ce09 feat: add safe shared SSO login guidance (central delivery) 2026-08-27 20:50:36 +00:00
jarvis-at-skic b629921b6f Merge pull request 'feat: include UI/UX in Corp v1 channel coordination' (#1) from feat/ui-ux-channel-sync into test 2026-08-25 01:18:38 -07:00
22 changed files with 1312 additions and 94 deletions

No files matched your search

+77
View File
@@ -0,0 +1,77 @@
# Full-program responsibility consolidation
Authorization: Piotras Board approval, [full approved program](https://discord.com/channels/1518726359512387766/1546489551235588138/1563064779772526616), as cited by the coordinating task. This local consolidation and canonical dependency binding makes no remote/runtime write, commit or publication. `SIMPLIFICATION.md` remains the historical minimum record.
The subsequent `contracts-audit.md` authority report was read in full and the coordinating instruction adopted its mechanical A05/A06/A08 mappings and A17 chronology. Only A02/A04 remain unresolved policy choices; A17 later-resumption evidence remains a bounded discovery gap.
## Effective baseline and publication gate
The installed `development-gates` 1.1.0 entry and review/CI reference carry complete-job-inventory, required aggregate and single-attempt safeguards; installed `devsecops-ci-cd-gitea-aerosim` 1.2.0 plus pipeline/conventions/Harbor references carry candidate image/chart packaging and aggregate inputs. Those inspected installed packages are the effective baseline, not unpublished additions in sibling worktrees. A separate worker reconciles their source packages. Before publication/adoption, verify complete published owner packages include these safeguards and record immutable revisions; this local result does not claim that reconciliation, publication or runtime refresh succeeded.
Exact-worktree/process-CWD checks and API task/run/UI identifier distinction remain in planning reconciliation: the inspected owners do not yet fully carry them. Likewise exact-context preflight and base-image consumer/repair contracts remain here. No unmatched safeguard was removed merely because a destination seems plausible.
## Clause-level disposition
| Finding | Implemented responsibility / retained clause / bounded remainder |
|---|---|
| A01 | Gate reference loads `development-gates` and its review/CI contract at candidate/CI/merge/integration decisions; attempt integrity and integration mechanics delegated. Six gate codes, all required validation classes, reviewer bindings, state transitions, deployment and handoff exits retained. A02/A04-sensitive sequence clauses retained rather than silently rewritten. |
| A02 | **unresolved**: substantive push-versus-review order. Existing stage 3 steps 5–6 retained; empty kickoff visibility is not a resolution. Await separate exact owner/Board resolution before affected extraction or conflicting execution. |
| A03 | Existing reviewer override preserved: main runtime reviews its candidate; AeroSim active worker reviews, main independently verifies evidence/remote effects. No second review worker or human-review dependency introduced; packet verification is not independent code review. |
| A04 | **unresolved**: harmless-base-drift clause versus generic synchronize/re-review. Stage 4 steps 2–3 retained and conflict explicitly bounded; no new harmless-drift exception inferred. |
| A05 | Removed stale “when practical” exemptions. AeroSim runtime binds observed product-reason unit RED, minimal GREEN/REFACTOR, isolated unpublished-delta discard only, preservation of unrelated/shared/integrated work, forward repair and honest historical missing RED. RootAtSkic alone grants a documented exception; no retrospective compliance. Central retains the same bounded discard/shared-work safeguard with its own project-authority exception; the generic owner update is coordinated separately. |
| A06 | AeroSim worker contract now distinguishes durable coordination of the complete frozen wave from executable per-Task claims: ledger includes blocked/unadmitted members without promotion, one live worker per eligible Task, canonical documentation persistence, verified lock ownership and orphan recovery. Per-Task gate ordering preserves authorized independent parallelism. No new status/admission gate or invented schema. |
| A07 | Planning/status/pitfalls load exact gates/integrity owners instead of repeating checkpoint algorithms. Retain Task-row semantics, current versus historical admission, non-approval interpretation, wave header/all-Task chapter, gate codes, source destinations and duplicate suppression. Full validator/build and exact-worktree residual checks retained. |
| A08 | AeroSim binds one focused repair attempt or one hour (whichever first) to sole-executor evidence handoff to main, existing-domain-owner advice, same-gate safe forward repair and continued independent Tasks. Advice is not a second implementer/reviewer; worker replacement needs verified ownership loss and durable handover. Central generic role mapping is coordinated separately; no project authority broadening. |
| A09 | AeroSim Actions reference is now overlay + exact CI owner/reference loads, not three duplicate workflow trees. Retains exact workflow names, all-app/code/image/chart/aggregate outcomes, credential and UAT boundaries. Runtime publication mechanics route to that owner; chart/GitOps integration bindings remain. Publication-ready owner verification is a hard prerequisite, not an assumption from sibling source edits. |
| A10 | Already resolved; preserve Delivery static/build-time artifact validations and candidate image/chart packaging. All functional non-unit suites remain UAT-owned; E2E never installs Helm or builds/publishes images. |
| A11 | Exact Task-release/unpadded-attempt branch naming, early visible PR, card links where applicable, `test` base, title equality and standing AeroSim merge delegation preserved. Generic branching cannot overwrite these project policies. |
| A12 | Board remains sole shared-login owner with decision-point load and fail-closed behavior. Specialist recovery load remains; exact own-account delegation, all stricter preconditions, transport interlocks, code guards and three-layer readback retained byte-identically. Recovery publication provenance remains unverified; no invented repository mapping. |
| A13 | Replaced repeated dataset/NFS/PV recipe with mandatory `home-v1--truenas` + `references/gondor-retained-application-storage.md` load before storage work. Durable non-deleting storage, environment isolation, approved authority and deployment-readiness remain. Selected Gondor skill and both AeroSim fallbacks retained; canonical GitOps, compatibility alias and generic base are installed and skill_view-tested by the parent, source `7ceb741c5fecbe34eb06e10a72e3ae26e3cc6f14`. No live StorageClass assertion. |
| A14 | Gate preflight now loads the one retained runtime preflight. Runtime loads scripts/monorepo owners for repository-root execution and committed versions. Task/cache isolation, every execution context and repository-native complete validation retained. AeroSim nested-pnpm recovery routes to its verified documentation owner; central fallback retained because global same-name source identity is unresolved. |
| A15 | Domain coverage remains Delivery-owned: five Ways of Working and five Engineering sections, verified not aspirational practice. Decision-point Docusaurus/Glossary loads own authoring/build/term mechanics. Removed duplicate synchronization enumeration in favor of entry/planning owners; no new documentation helper. |
| A16 | Duplicate evidence/toolchain pitfalls become owner loads. Retain project lock-holder verification and complete base-image contract including credential-free candidate checks, trusted publication, immutable digest consumption and last known-good forward repair. No CI-owner ownership of that unmatched contract asserted. |
| A17 | Authority audit found original RootAtSkic hourly/60-minute requests (1546990225669234820, 1550892376900509817) and explicit stop (1552094167901937676). AeroSim entry replaces unconditional scheduling with conditional mechanics and a versioned approval/stop/resumption record. Later bot-reported reconciler 6777dc7d3d82 does not prove reauthorization or current inventory; bounded resumption evidence remains outstanding. No scheduler mutation or unauthorized-job finding. See entry chronology for exact links. |
| A18 | Eight-channel wording corrected in AeroSim gates; authorized channel boundary unchanged. Worker cache diagram no longer places Playwright/PostgreSQL under Delivery. DEV tuple, UAT verdict and verified separate Releases-channel handoff remain distinct; no `DONE` or release authority moved. |
## Verification contract
Tests precede content edits. Whole-file hashes for intentionally thinned references are replaced with checks of exact protected clauses plus semantic routing/outcome tests, not with deletion of safety coverage. Unchanged metadata, authority blocks, self-recovery source and delegation guards retain original hashes. Run every test module (including standalone `main()` scripts), the recovery tests with their declared websocket dependency, local Markdown-link validation and `git diff --check`. Report local results only; no repository CI or publication is implied.
## Original consolidation verification result
- Command: `/opt/hermes/.venv/bin/python tests/verify_full_program.py` — **21 checks passed**, including standalone test functions/main scripts that unittest discovery alone misses.
- Local operational Markdown links: **29 resolved**; `git diff --check` passed.
- Entry + all references: **80,924 → 76,537 bytes** (4,387 fewer). References alone: **57,907 → 53,520 bytes** (4,387 fewer). Audit records and tests excluded; new authority chronology/mappings are included. This is a measured reduction, not a dramatic token-saving claim.
- Plain system Python lacked `websockets`; the existing Hermes venv supplied it. No dependency installation or runtime skill update was performed.
- No remote CI/publication, live deployment, scheduler or account mutation was attempted. Required dependency publication readback and A02/A04 owner choice remain coordinating gates.
## Canonical dependency acceptance update
The parent reports merged and installed owner packages: `development-gates` at `02e716ddff053c71a921839419ed2bd2334f1e67`, `development-integrity` at `3ca0fbb284b5eb194ad5ff1f2756f1fde0077c6a`, `development-method-ttd` at `d3d91be7bb2926b0f1bd16db60c0fe2250ed8d39`, and `development-durable-wave-execution` at `a180018ef3bc337bb1fbabd095fa7a4e13471fc5`. This supersedes their earlier pending reconciliation description above; it is coordinating evidence, not a runtime action performed here. GitOps canonical `development-gitops-argo-cd-home-gondor-v1`, alias and generic base were installed and skill_view-tested by the parent at source `7ceb741c5fecbe34eb06e10a72e3ae26e3cc6f14`. Conditional fallbacks remain for unavailable future installations. Other canonical owners are being published by the parent; no unverified publication success is inferred. Legacy source URLs and historical records remain provenance, not additional owners. `corp-v1-glossary` remains unchanged pending the public-to-private repository decision. A02/A04 still await human resolution.
Canonical-binding verification: see [naming-delivery-review.md](naming-delivery-review.md) for the subsequently executed complete standalone harness results and unchanged golden-hash strategy.
## Final bounded owner consolidation
This supersedes the earlier A14/A16 statements that reusable preflight/base-image mechanics lack an owner. Delivery retains the project bindings and outcomes; only the matched mechanics moved. A02/A04 and their golden clauses remain unchanged and unresolved.
| Moved reusable clause | Exact source-owner section |
|---|---|
| version resolution, executable/version comparisons | `development-scripts/references/runtime-preflight.md` — Required inputs; Procedure 1–2 |
| presence-only environment and repository identity/state checks | `development-scripts/references/runtime-preflight.md` — Procedure 3–4 |
| same-context activation, inheritance failure classification and complete retry | `development-scripts/references/runtime-preflight.md` — Procedure 5; Failure and repair |
| image folder/metadata, digest/tool/platform/user/workspace/trust assertions and lockfile parity | `devsecops-ci-cd-gitea/references/base-images.md` — Construction and static contract |
| credential-free candidates and isolated trusted publication | `devsecops-ci-cd-gitea/references/base-images.md` — Candidate isolation and trusted publication |
| full-source tags, direct Harbor readback, immutable retry and aggregates | `devsecops-ci-cd-gitea/references/base-images.md` — Immutable publication and direct readback |
| digest consumer verification and forward repair mechanics | `devsecops-ci-cd-gitea/references/base-images.md` — Consumer verification and forward repair |
| negative trigger/tag/secret/interpolation/digest/setup regression cases | `devsecops-ci-cd-gitea/references/base-images.md` — Fail-closed regression matrix |
Immutable CI-owner acceptance: source `669e28eadfe79ac7cb3c10ccdea318dd5296d481`; installed/source base-image reference SHA-256 `1fb0e24ec5789b195be9ae35fbb9529fa1cab56112dae5baf9455284ca490e53`, independently compared locally. `owner-responsibility.json` covers both callers. Scripts source was inspected at HEAD `5960d5e74713e6b95a403962f479b2b97cb76286`, with reference content SHA-256 `07306382b8afe5c2d2e83e2955a04a1523d008e7e39cead7c7a1797bb6640462`; the content hash, not HEAD alone, identifies the inspected working-tree contract. Scripts semantic reconciliation/publication/install remains a parent gate before Delivery publication/adoption. Record the final immutable published revision and source/runtime equality there; no pending result is claimed here.
Retained locally: every foreground shell/worktree/background process/worker/main review/CI context, stop-on-failed-preflight, selected Task containment/repository/revision/namespace and allowed command scope, complete repository CI, trusted `test` branch and named project base-image repository, immutable consumer evidence, separate UAT acceptance, forward repair and last known-good digest. All unique project chart/runtime/storage/recovery boundaries remain unchanged.
Test manifest: `tests/owner-consolidation-manifest.json` preserves inspected owner text/hash and exact clause-to-section moves. Only the two intentionally moved runtime section hashes are retired into that manifest; semantic regression checks replace them. All unrelated golden hashes and canonical identity normalization are unchanged. New tests first failed on missing decision-point loads in both packages, before content edits.
## Published owner adoption checkpoint
The final preflight owner is `global-skills/development-scripts` at `0e36552938da94c0539e39b35256b8effe34c25d`; the base-image owner is `global-skills/devsecops-ci-cd-gitea` at `669e28eadfe79ac7cb3c10ccdea318dd5296d481`. Both complete packages were authenticated-readback verified and installed byte-for-byte. The preflight hash is `07306382b8afe5c2d2e83e2955a04a1523d008e7e39cead7c7a1797bb6640462`; the base-image hash is `1fb0e24ec5789b195be9ae35fbb9529fa1cab56112dae5baf9455284ca490e53`. Earlier preparation-stage pending-owner statements above are historical and superseded by this checkpoint. Generic scripts preserves the existing Home/SKIC adoption body in a scoped reference; it does not silently replace the adopted bootstrap convention. No remote CI was configured for these two owner repositories; local contract tests and independent source review passed. This checkpoint resolves the owner-publication prerequisite only, not A02/A04, scheduler reauthorization, remaining organization visibility or other-project adoption decisions.
+75
View File
@@ -0,0 +1,75 @@
# Bounded Delivery simplification — 2026-10-23
## Authority and boundary
GUILD-IMP-20261023-delivery-existing-owners. Piotras (`501954115690168321`), verified Board member, approved “implement delivery skills proposal” in [Guild message 1563054836508008539](https://discord.com/channels/1518726359512387766/1542596418215092264/1563054836508008539), as supplied by the commissioning parent. This record does not claim an independent Discord re-audit.
Implements only the [published recommendation / smallest useful change](https://pages.apps.lego-cloud.eu/corp-v1-aerosim/corp-v1-aerosim-documentation/engineering/skills-delivery-channel#smallest-useful-change), read from `delivery-proposal-refresh-20261023/engineering/skills-delivery-channel.mdx`, with [2026-10-23 source/finding evidence](https://pages.apps.lego-cloud.eu/corp-v1-aerosim/corp-v1-aerosim-documentation/evidence/delivery-skills-refresh-2026-10-23.json). Baseline: `225ae3b068d97748af69597353479eb9c26579fc`, version 1.14.1; candidate 1.14.2.
Central package only; no helper, dependency change, file removal, migration, policy choice, dependency-repository edit or documentation-project edit. This manifest is an audit artifact, not an operational loaded reference. Parent owns publication, runtime refresh and separately authorized semantic project adoption.
## Responsibility manifest
Each row states the old rule/location, retained or single owner, and the new load point. Unlisted operational paragraphs remain unchanged.
| Rule / before | After: owner and decision point | Retained outcome / limit |
|---|---|---|
| Login origin and authorized purpose — entry + runtime repeated Board policy | Board **Corp v1 System SSO Credential Use**; entry says load before login, runtime follows that binding | Origin/purpose verification remains mandatory; unavailable owner stops login |
| Login secret names/runtime-only use — same two copies | Board; same pre-login load | Exact names retained in entry; no secret values introduced |
| No inspect/print/hash/serialize/paste/log/screenshot/persist or unsafe transport — same copies | Board full policy, not a selected subset | Board rules 2–3 and 7–8 retain all restrictions and session safety |
| Missing secret names only; never ask for values — same copies | Board rules 2–4, pre-login load | Injection only, no fallback secret |
| Login is not account/credential/MFA/permissions/billing/destructive authority | Board plus short Delivery boundary | No recovery or additional authority granted |
| Canonical lifecycle vocabulary repeated entry + status reference | Existing status reference owns full vocabulary; entry loads it before status action | Exact Task admission/claim, separate BLOCKED, TO_BE_RELEASED vs DONE retained in entry; full statuses unchanged in reference |
| Ways of Working five sections repeated entry + failure reference | Existing failure reference owns domain coverage; entry loads it before edits | All ten domain sections remain; verified practice only, not aspirations |
| Documentation platform mechanics | Global Docusaurus + project overlay; failure reference before authoring/validating | Source identity must match, not unrelated same-name VSSA installation; no domain/Diátaxis conflation |
| Canonical reusable definitions | Existing global Glossary; failure reference before defining terms | Final top-level Glossary and domain links, not copied explanations |
| Nested pnpm/Corepack bootstrap recipe — planning step 5 | Retained unchanged locally pending resolution of global Docusaurus runtime identity | Published owner has the procedure, but the installed name currently resolves to an unrelated source; no extraction to an unverified runtime owner |
| Current checkpoint/report claims — planning steps 8/12 | Integrity evidence-first sequence; explicit before-report load in planning/status | Fresh source/merge distinction, revalidation on drift/merge/close, final equality and duplicate suppression retained locally |
| Report shape and lifecycle meaning | Delivery status reference remains owner | Requested wave header, every Task, real owner, linked PR, gate codes, failure classification and no automatic DONE unchanged |
| pnpm/script implementation routing — runtime Coding | Existing pnpm and scripts owners with source-table link and action triggers | Approved Feature/Task, structure/namespace, traceability, no unrelated refactor/fabrication remain |
| Unit mechanics — runtime Unit testing | Explicit TTD action load added; existing generic owner already routed in entry | Existing bullets and Task stage left intact; no choice on discard/forward repair |
| Failure diagnosis/forward-repair procedure repeated entry + failure reference | Existing failure reference; entry loads at observed failure | Complete reference repair and escalation text unchanged, including no premature stop/help-policy rewrite |
| Build/CI failure classes repeated runtime + entry | Entry owns classes; runtime loads it and Integrity before reporting | Task CI job inventory and exact-head requirements untouched |
| Base-image policy repeated entry + runtime | Existing runtime reference owns complete contract; entry loads before create/publish/consume | Digest, version/platform/non-root/tools, candidate secret isolation, immutable publication/readback, fail-closed tests, lockfile parity, separate layers, forward repair/last-good all retained |
| Pitfalls duplicated entry + reference | Existing pitfalls reference, loaded on failed/resumed work and before status | Full reference unchanged; no safeguarding rule deleted |
## Verified existing sources
Source audit used the published capture, not version-label equality. No owner content was copied into a new helper or changed in this task.
- [Board login owner](https://gitea.lego-cloud.eu/skic-skills/channel-board-skic/src/commit/9170a6749f0adf5ec65fc99a645600cb471be9f1/SKILL.md): published/installed equal in evidence; loaded for comparison.
- [Integrity reporting owner](https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-integrity/src/commit/b677c99f24cbe83734a9d6a495e388837fc88701/SKILL.md): published/installed equal; loaded for comparison.
- [Global Docusaurus](https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus/src/commit/699cf6786e02bef74e84ec64b5a6233d4839ed47/SKILL.md): full captured `remote_text` read from `delivery-refresh-evidence/documentation-source.json`, including nested-pnpm remedy. Direct unauthenticated fetch returned 404; no false live-readback claim. Skill loader resolves a different VSSA owner; operational loads now explicitly require correct provenance.
- [Glossary](https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1-glossary/src/commit/24732bf6864a14f2d6aa6cccd7d9fc023438a42d/SKILL.md): retained existing route; no glossary procedure extracted.
- [TTD](https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-method-ttd/src/commit/2155b0a250cea282bf6628231d8e3de286522a86/SKILL.md): retained strict existing route, no discard-policy rewrite.
- Ordinary Git, pnpm and scripts source links remain in the unchanged Development Skill Routing table. No Git procedure is extracted because exact Task/branch/readback requirements are tightly coupled to unresolved gates.
## Deferred findings and untouched boundaries
A01: no gate algorithm extraction; published `development-gates` lacks installed complete-job-inventory protections. A02/A04: substantive push/review order and harmless-base-drift wording untouched. A03: main-session review/worker restrictions unchanged. A05: strict TTD route retained, weaker wording/local-discard versus valid-work forward repair not reconciled. A06: whole-wave claim mapping not chosen. A08: no help-threshold/worker-role decision. A09: project CI source/runtime drift not changed. A10: no obsolete Helm fix needed; current static artifact versus functional UAT boundary retained. A11: exact branch/title/attempt/early-PR identity untouched. A12: no recovery skill or authorization change. A13: GitOps loadability/storage source issues not solved; all runtime/storage safeguards retained. A14: exact-context preflight remains byte-identical. A15: domain/platform distinction retained. A16: base-image safeguard remains local, not delegated to an incomplete external owner. A17: no scheduler authority conclusion or job mutation. A18: central eight-channel boundary unchanged; no project cleanup here.
The four complete files `task-delivery-gates.md`, `repository-entry-and-visibility.md`, `common-pitfalls.md`, `aerosim-lessons-review.md` are byte-identical. Runtime workspace, exact-context preflight/base-image/runtime-resource tail, failure-repair procedure and entry Authority/Escalation are hash-locked in tests. All 12 metadata dependencies and all 8 references remain.
## Validation and operational footprint
Test-first: initial unittest run had 12 tests, with expected failures for missing load points and size reduction (2 failures). Final suite includes unittest classes and the three existing function-style routing tests through `unittest.FunctionTestCase`; plain discovery alone would miss those three. No network required by tests.
Final local validation: `uv run --with pytest python -B -m pytest tests -q` — 16 tests passed. `git diff --check` passed. No remote CI workflow is configured. Publication/installation is separately verified by the parent.
## Measured operational footprint
Includes entry and every reference; excludes this audit manifest, tests, adoption record and caches. No removed procedure was moved into an operationally loaded new file.
| File | Before bytes | After bytes | Reduction |
|---|---:|---:|---:|
| `SKILL.md` | 27413 | 23017 | 4396 |
| `references/aerosim-lessons-review.md` | 3400 | 3400 | 0 |
| `references/common-pitfalls.md` | 2276 | 2276 | 0 |
| `references/failure-and-documentation.md` | 4428 | 5136 | -708 |
| `references/planning-artifact-reconciliation.md` | 6624 | 6621 | 3 |
| `references/repository-entry-and-visibility.md` | 6514 | 6514 | 0 |
| `references/runtime-and-ci.md` | 11078 | 10654 | 424 |
| `references/status-and-reporting.md` | 5135 | 5385 | -250 |
| `references/task-delivery-gates.md` | 17921 | 17921 | 0 |
| **Total** | **84789** | **80924** | **3865 (4.56%)** |
+119 -94
View File
@@ -1,41 +1,72 @@
---
name: corp-v1-channel-delivery
name: channel-delivery-skic
description: "Use when operating or synchronizing a Corp v1 project's delivery channel. Drives coding, unit testing, build and continuous-integration health, attempts safe evidence-based fixes, escalates requirement or architecture contradictions, and maintains Ways of Working and Engineering documentation."
version: 1.5.1
version: 1.15.0
author: Hermes Agent
license: MIT
metadata:
hermes:
tags: [corp-v1, discord, channel, delivery, coding, testing, ci]
related_skills: [corp-v1--main, home-v1-discord, documentation-docusaurus, corp-v1--glossary]
related_skills: [channel-board-skic, discord, documentation-docusaurus, corp-v1-glossary, development-durable-wave-execution, development-gates, development-integrity, development-method-ttd, development-branching-strategy, development-monorepo-pnpm, development-scripts, development-gitops-argo-cd-home-gondor-v1]
---
# Corp v1 Delivery Channel
# SKIC Delivery Channel Reference
## Overview
This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases` channels and implements only tasks whose parent Feature has explicit human `Approved for Implementation` evidence and which a human team member separately admitted to Kanban Focus `InBacklog`.
## Hermes Kanban direct-link contract
Whenever a response mentions a Hermes Kanban board, initiative, card, or task, it must include a direct dashboard link in the form `[descriptive board label](<dashboard-public-url>/kanban?board=<board-slug>)`. Resolve the dashboard public URL and exact board slug before reporting; never provide only a board name, slug, card count, “visible cards,” or “available in the dashboard.” If no task-specific deep link exists, link the board and include the exact task ID or title in the same statement. Project-adopted skills must replace this generic form with their verified project board URL.
## Canonical Scope Status Vocabulary
Before reporting or changing lifecycle status, load [status-and-reporting.md](references/status-and-reporting.md) and read the project's current Ways of Working Scope page. That contract retains the complete canonical vocabulary, requested wave format and gate codes; `development-integrity` owns checkpoint claims. Delivery claims only an exact `READY_FOR_DELIVERY` Task into `IN_PROGRESS`, without a second Focus admission. `BLOCKED` remains a separate flag; merge/green CI is not `DONE`, and releasable application work normally ends Delivery at `TO_BE_RELEASED`.
This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, `uat`, and `releases` channels and implements only tasks whose parent Feature has explicit human `Approved for Implementation` evidence and whose exact Task status is `READY_FOR_DELIVERY`. That status is the Focus-admitted pickup handoff; no separate post-status admission gate exists.
Its scope includes coding, unit testing, builds, continuous integration, review readiness, delivery blockers, and maintenance of the project documentation's `Ways of Working` and `Engineering` areas.
Delivery owns application **unit testing only** plus static/build-time validation of the application artifacts it publishes: Dockerfiles, image/container contracts, publication records/workflows, and Helm chart linting/rendering/packaging. The project's standalone E2E repository under its UAT channel owns every functional non-unit suite and its fixtures, configuration, runner, and evidence: integration, browser, E2E, acceptance, security-boundary, performance, runtime-budget, smoke, regression, and deployed-environment testing. Delivery must not maintain or execute functional non-unit suites in the application repository. E2E must not install Helm or build/publish application images. It consumes UAT failures as defect evidence, fixes application code with unit-first TTD, and hands the corrected deployed tuple back to UAT.
Load the global `documentation-docusaurus` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus` before changing documentation structure, navigation, Markdown/MDX, Docusaurus configuration, or builds.
Load the global `corp-v1--glossary` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1--glossary` whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level **Glossary** area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.
Load the global `corp-v1-glossary` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1-glossary` whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level **Glossary** area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.
## Shared Corp v1 System Login
Before login, load `channel-board-skic` from [its authoritative source](https://gitea.lego-cloud.eu/skic-skills/channel-board-skic) and follow **Corp v1 System SSO Credential Use** in full. It owns origin/purpose verification, runtime-only `HL_V1_SSO_EMAIL` / `HL_V1_SSO_PASSWORD` handling, non-disclosure, missing-secret injection and session safety. If that policy cannot be loaded, stop before login. Secret availability is not authorization; Delivery grants no account recovery, credential/MFA, permission, billing, destructive-operation or unrelated-access authority.
## When to Use
Use this skill when:
- operating in `corp-v1-<code>-delivery`;
- operating in `<code>-delivery`;
- running its recurring synchronization job;
- implementing or reviewing project code;
- adding or repairing unit tests;
- adding or repairing unit tests only; non-unit coverage is routed to the project's UAT channel and standalone E2E repository;
- diagnosing build or CI failures;
- checking implementation against requirements and ADRs;
- maintaining delivery-oriented documentation.
Do not use it to silently choose between contradictory requirements or architecture decisions, approve releases, or bypass review and branch protections.
## Development Skill Routing
This channel skill owns **delivery governance and project-channel coordination**. Reusable engineering procedures belong to the global `development-*` skills below; load the matching skill before the action and treat a project-adopted variant as the project-specific overlay when one exists.
| Work | Required reusable skill | Authoritative Gitea source |
|---|---|---|
| dependency-wave claim, continuation, recovery, and closure | `development-durable-wave-execution` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-durable-wave-execution |
| immutable candidate review, exact-head CI, merge, and integration gates | `development-gates` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-gates |
| delivery, CI, blocker, and completion reporting | `development-integrity` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-integrity |
| behavior changes, defect fixes, and refactoring | `development-method-ttd` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-method-ttd |
| branch naming, worktrees, PR topology, and base synchronization | `development-branching-strategy` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-branching-strategy |
| pnpm/TypeScript monorepo implementation | `development-monorepo-pnpm` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-monorepo-pnpm |
| Taskfile, `.scripts/`, shell wrappers, environment validation, and Devbox | `development-scripts` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-scripts |
| Gondor Argo CD template, rendered desired state, and repository connection | `development-gitops-argo-cd-home-gondor-v1` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-gitops-argo-cd-gondor-v1 |
The channel skill may narrow authority, lifecycle, workspace, visibility, handoff, and evidence requirements. When a project/channel overlay conflicts with a reusable skill on branch naming, human confirmation, worker count, review identity, merge authority, deployment authority, or release authority, the explicit project/channel overlay wins; inherit only the non-conflicting mechanics. It must not restate generic RED–GREEN–REFACTOR mechanics, shell-module layouts, pnpm workspace conventions, ordinary Git branching mechanics, exact-head gate algorithms, or Argo CD authoring procedures. Improve those reusable skills at their linked sources and keep only the project/channel overlay here.
## Implementation Entry Gate
Before starting or continuing Feature implementation, verify in project documentation:
@@ -46,26 +77,33 @@ Before starting or continuing Feature implementation, verify in project document
- task breakdown and dependencies;
- target version and status;
- acceptance evidence expected from delivery.
- explicit human Kanban approval admitting the exact task to Focus `InBacklog`.
- exact Task `READY_FOR_DELIVERY` evidence, which itself records human Kanban Focus admission.
Hermes cannot approve a Feature for implementation or admit a task to Focus `InBacklog`. If the gate is incomplete, improve safe delivery-readiness documentation or raise the exact missing decision in `architecture`; do not start code.
Hermes cannot approve a Feature for implementation or move a Task to `READY_FOR_DELIVERY`. Once that exact state exists, Hermes must not require a second Focus-admission decision; Delivery claims the Task by moving it to `IN_PROGRESS`.
## Immediate Wave-Start Visibility Gate
Load `development-durable-wave-execution`, `development-branching-strategy`, and `development-gates` before claiming or starting a wave. Those skills own durable whole-wave claims, branch/worktree mechanics, immutable candidate identity, and exact-head review/CI behavior.
The Corp v1 overlay is narrower: every Task requires a dedicated visible branch and PR before substantive coding, and that PR must carry the Task ID, wave, planned scope, current state, exact head, and governed `test` base. If Gitea requires a delta, use an empty kickoff commit rather than a filler file. Read the branch and PR back before editing. One Task maps to one branch and PR unless Architecture or the human owner explicitly approves another topology.
## Proactive Iteration Requirement
Every delivery iteration must complete at least one useful, safe activity for an implementation-approved Feature or delivery-health need: implement an unblocked task, add tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, verify dependency readiness, or document a concrete blocker with evidence. Never create filler changes. Select work only from Kanban Focus `InBacklog`, backed by architecture's approved task/dependency plan, and update progress in project documentation.
Every delivery iteration must complete at least one useful, safe activity for an implementation-approved Feature or delivery-health need: implement an unblocked task, add unit tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, verify dependency readiness, or document a concrete blocker with evidence. Never create filler changes. Select work only from exact Tasks in `READY_FOR_DELIVERY`; claiming one moves it to `IN_PROGRESS`. Keep architecture's approved task/dependency plan and project documentation current.
## Approved Information Boundary
Inspect only the project's seven channels:
Inspect only the project's eight channels:
```text
corp-v1-<code>-general
corp-v1-<code>-scope
corp-v1-<code>-architecture
corp-v1-<code>-ui-ux
corp-v1-<code>-kanban
corp-v1-<code>-delivery
corp-v1-<code>-releases
<code>-general
<code>-scope
<code>-architecture
<code>-ui-ux
<code>-kanban
<code>-delivery
<code>-uat
<code>-releases
```
Use enough delivery history to avoid duplicate work and only relevant new activity from the other channels. Never inspect another project.
@@ -74,80 +112,39 @@ Use enough delivery history to avoid duplicate work and only relevant new activi
### Coding
- implement only human-approved Features and their authorized tasks;
- load applicable project engineering skills before changing code;
- preserve project structure, conventions, and environment namespace;
- keep changes small, reviewable, and traceable to requirements/issues;
- avoid unrelated refactors during failure repair;
- never fabricate command, test, CI, or deployment results.
Load the project-adopted engineering skill for the repository stack before editing. `development-monorepo-pnpm` owns pnpm/TypeScript workspace implementation, while `development-scripts` owns Taskfile, `.scripts/`, shell-wrapper, environment-validation, and Devbox conventions. Delivery adds only the approved requirement/Task boundary, traceability, and prohibition on unrelated refactoring or fabricated evidence.
### Unit testing
- add or update tests with behavioral changes;
- reproduce defects before fixing when practical;
- cover normal, edge, and failure cases proportional to risk;
- run the narrowest relevant tests first, then required broader validation;
- record exact commands and real results.
Load `development-method-ttd` for every behavior change, defect fix, or refactor. It owns RED–GREEN–REFACTOR mechanics, focused-test progression, and test-design anti-patterns. Delivery requires unit tests to map to approved acceptance evidence and retains their real commands/results. UAT owns every functional non-unit test required to prove that evidence outside the unit boundary; Delivery retains build-time image/container/Helm artifact validation.
### Build and continuous integration
Monitor local builds and Gitea Actions for:
Load `development-gates` before candidate review, remote CI, merge, or integration validation, and load `development-integrity` before reporting their status. These skills own exact-head identity, attempt integrity, base-drift handling, candidate-versus-integration separation, and honest checkpoint wording.
- compile/type failures;
- unit/integration test failures;
- lint/format failures;
- dependency, packaging, container, or chart failures;
- workflow/configuration defects;
- missing or stale artifacts;
- branch/head-SHA mismatch.
Delivery still monitors repository-specific compile/type, unit-test, lint/format, dependency, packaging, workflow, image/container contract, Helm chart, and artifact-publication failures. Functional non-unit browser, integration, performance, security-boundary, and acceptance failures arrive as UAT evidence and are routed back for application remediation. A green local build is never remote CI evidence.
A green local build is not proof that CI or delivery succeeded. Verify the actual remote branch and matching CI task/run.
### Per-project reusable CI base images
Each project should own `corp-v1-<code>/corp-v1-<code>-base-images` when stable runtimes or OS tools would otherwise be downloaded repeatedly in CI. Before creating, publishing or consuming an image, load [the project base-image bindings and required owner loads](references/runtime-and-ci.md#per-project-reusable-ci-base-images). It retains digest pinning, credential-free candidate validation, trusted integration-branch publication, immutable tags/digest readback, fail-closed tests and forward repair with the last known-good digest. Runtime smoke remains UAT-owned; reusable mechanics are owned by `devsecops-ci-cd-gitea` through that decision-point reference.
### Runtime-resource placement
CI jobs and developer workstations must not provision databases, queues, object stores, caches, brokers, or other application runtime services. When implementation or validation needs such a resource, provision it under the owning application on the approved shared runtime platform through that project's GitOps repository, then consume it through a governed application or test interface.
- Keep every non-production environment—including development, integration, test, staging, and preview—and all of its resources isolated from production and from other non-production environments. Destructive or concurrent validation requires a per-run database/schema/role or explicit serialization; it must not reset shared data.
- CI may orchestrate exact-head validation, but it must not start application runtime-resource service containers or receive application-resource credentials. Harmless process-local test doubles and build tools are not runtime resources. Prefer a narrowly governed in-platform Job/Workflow trigger so a private resource does not need public, NodePort, or runner-network exposure.
- Persistent storage must follow the project's named platform storage operations skill; load that skill before designing or mutating storage. If the project instead names an approved storage procedure, read that exact procedure and verify its current provenance before acting. If neither an approved skill nor an approved procedure is identified, stop and route the missing decision to Architecture/platform operations; do not infer a provider or provisioning method. Never accept a dynamically provisioned volume whose reclaim policy can delete durable data when the PVC is removed.
- Secrets come from the approved external secret store; never commit connection strings or credentials.
- Provision and verify required runtime resources before treating dependent application work as deployable. Missing infrastructure blocks deployment, not safe code-only work whose tests do not require that resource.
## Failure-Repair Workflow
When a build or CI failure is observed:
1. verify repository, branch, head SHA, failed job, and exact logs;
2. reproduce locally when feasible;
3. determine root cause before editing;
4. compare the intended fix against approved FR/NFRs, ADRs, architecture documentation, and project conventions;
5. implement the smallest safe fix;
6. add/update tests where behavior changed;
7. run local validation;
8. commit and push through the approved branch workflow;
9. inspect CI for the exact new head SHA;
10. report evidence and remaining risk.
The skill may attempt a safe fix when the failure and expected behavior are clear. If evidence is insufficient or requirements/architecture conflict, stop and raise the issue in the relevant channel:
- requirement/product ambiguity → `general` and/or `architecture` as appropriate;
- architecture contradiction → `architecture`;
- release policy/readiness ambiguity → `releases`;
- implementation-only blocker → `delivery`.
Never guess the team's intended direction.
Load [failure-and-documentation.md](references/failure-and-documentation.md#failure-repair-workflow) when a build or CI failure is observed. It owns diagnosis, safe forward repair, affected validation, exact-head CI and escalation destinations. Keep repairable failures in the same Task/gate; pause only for the documented external, authority, decision or safety blocker. Never guess requirements or Architecture, weaken a gate or treat a blocker as passing.
## Documentation Ownership
Maintain two documentation areas.
### Ways of Working — five sections
1. **Delivery workflow** — intake, prioritization, implementation states, and definition of done.
2. **Branching and reviews** — branch conventions, pull requests, approvals, and merge expectations.
3. **Planning and ownership** — backlog, sequencing, owners, dependencies, blockers, and escalation.
4. **Quality practices** — review standards, test strategy, defect handling, and evidence expectations.
5. **Collaboration and decisions** — channel routing, handoffs, decision references, and communication norms.
### Engineering — five sections
1. **Repository and workspace** — monorepo/application/package structure and local prerequisites.
2. **Development and testing** — commands, unit/integration testing, fixtures, and debugging.
3. **Build and continuous integration** — pipelines, checks, artifacts, runners, and failure diagnosis.
4. **Packaging and deployment preparation** — containers, Helm/GitOps interfaces, configuration, and release inputs.
5. **Operations and troubleshooting** — observability, known failure modes, recovery checks, and evidence collection.
Update these pages from verified project practice. Do not document a planned process as already operational.
Delivery owns verified Ways of Working and Engineering content, not documentation-platform mechanics. Before changing either area, load [the domain coverage contract](references/failure-and-documentation.md#documentation-ownership), the linked global `documentation-docusaurus` source and the project-adopted documentation overlay. Load `corp-v1-glossary` before defining reusable terms. Keep planned practice distinct from operational evidence.
## UI/UX Coordination
@@ -156,7 +153,7 @@ For frontend-affecting work, Delivery requires the approved UI/UX design package
## Synchronization Workflow
1. Read new same-project activity and enough delivery history to avoid duplicates.
2. Verify human `Approved for Implementation` evidence, explicit human Kanban Focus `InBacklog` admission, task dependencies, and target version before task work.
2. Verify human `Approved for Implementation` evidence, exact Task `READY_FOR_DELIVERY` state, task dependencies, and target version before task work.
3. Identify executable tasks, CI failures, blockers, requirements/ADR implications, and documentation drift.
4. Load all applicable project engineering skills.
5. Complete at least one useful safe activity when an authorized path exists; otherwise document and route the exact blocker.
@@ -169,9 +166,9 @@ For frontend-affecting work, Delivery requires the approved UI/UX design package
May autonomously:
- run tests/builds/read-only checks;
- run unit tests, builds, Delivery artifact validations, and read-only checks; functional non-unit suites run through UAT;
- repair clear CI/build defects within authorized scope;
- add tests for an approved behavior;
- add unit tests for an approved behavior and request non-unit coverage from UAT;
- maintain accurate delivery documentation;
- prepare branches/commits/PRs where the project workflow authorizes it.
@@ -187,26 +184,45 @@ Requires approval before:
Include repository, branch, commit SHA, changed paths, commands, local results, CI run/task IDs and status, and relevant requirement/ADR references. Report blockers honestly.
## Mined Project-Adoption Improvements
Review provenance and exclusions: [AeroSim lessons review](references/aerosim-lessons-review.md).
## Dedicated Project Channel Workspace
Every project adoption must bind this channel to a dedicated local workspace under the active working root. Keep clones, worktrees, plans, reports, screenshots, generated artifacts, retained logs, and channel inputs inside that channel root. Use run-unique or task-specific children under `workspace/`; keep durable project truth in approved repositories. A local folder boundary organizes execution only—it neither broadens authority nor replaces remote evidence. Delivery adoptions should additionally use a channel-level `cache/` for reusable pinned toolchains and dependencies, while keeping Task evidence isolated by Task.
## Project-Adoption Delivery Lessons
Use the exact Task-file state. The canonical progression is `IN_BACKLOG → READY_FOR_DELIVERY → IN_PROGRESS → TO_BE_RELEASED → DONE`; `BLOCKED` is a separate reasoned flag, and neither merge nor green CI means `DONE`. A Task already in `READY_FOR_DELIVERY` is Focus-admitted and pickup-ready; Delivery claims it by moving directly to `IN_PROGRESS` without inventing a second admission gate.
Keep exactly one Task active unless the adopted project authority explicitly defines another safe model. Establish a visible branch and PR before implementation, freeze Task/branch/PR identity, verify every review against the exact candidate head, and end Delivery ownership at `TO_BE_RELEASED`. Failed gates remain active and are repaired forward until they pass or a genuine external, authority, decision, or safety blocker is evidenced.
Load the matching detailed reference at the decision point—not from memory:
- Task selection, execution, review, merge, and handoff: [references/task-delivery-gates.md](references/task-delivery-gates.md)
- Status, wave, blocker, CI, and completion wording: [references/status-and-reporting.md](references/status-and-reporting.md)
- Workspace, branch, PR, and visibility entry: [references/repository-entry-and-visibility.md](references/repository-entry-and-visibility.md)
- Toolchain contexts, CI, images, and runtime placement: [references/runtime-and-ci.md](references/runtime-and-ci.md)
- Failure repair and Delivery-owned documentation: [references/failure-and-documentation.md](references/failure-and-documentation.md)
- Planning-artifact reconciliation: [references/planning-artifact-reconciliation.md](references/planning-artifact-reconciliation.md)
- Gate failures, resumptions, blockers, merge, and completion: [references/common-pitfalls.md](references/common-pitfalls.md)
Project adoptions may narrow execution to a named main session or prohibit subagents/cron. Preserve that project-local authority overlay; the central reference does not grant account recovery, permission changes, merge, release, or deployment authority.
When selectable controls are needed, explain every complete option and its trade-offs in prose first, then use short `Option A`, `Option B`, and so on labels in the control. Put the recommended option first and keep button labels free of hidden consequences.
## Common Pitfalls
1. Patching symptoms before understanding root cause.
2. Changing requirements or architecture implicitly through code.
3. Claiming CI success from a local build.
4. Editing without loading applicable project engineering skills.
5. Skipping tests for behavioral fixes.
6. Updating documentation with aspirational rather than actual practice.
7. Repeatedly posting unchanged failure summaries.
8. Inspecting another project.
9. Starting implementation because requirements exist but human implementation approval is absent.
10. Ignoring architecture task dependencies, Kanban Focus admission, or target-version allocation.
11. Posting passive status when safe implementation, testing, diagnosis, or documentation work is available.
Load [common-pitfalls.md](references/common-pitfalls.md) on failed gates, resumed work and before blocker/CI/merge/completion reports. It retains the complete Delivery traps, including approval/admission, same-project scope, useful safe activity, real evidence and same-gate forward repair. These reminders do not replace the ordered Task gates.
## Verification Checklist
- [ ] Only same-project channels and repositories were used.
- [ ] Work maps to approved requirements/architecture.
- [ ] Feature has explicit human `Approved for Implementation` evidence and a documented target version.
- [ ] Selected tasks respect documented dependencies and have explicit human Focus `InBacklog` admission.
- [ ] Selected tasks respect documented dependencies and carry exact Task `READY_FOR_DELIVERY` evidence.
- [ ] At least one useful delivery activity was completed, or a concrete blocker was documented and routed.
- [ ] Applicable project skills were loaded.
- [ ] Tests and builds were actually run.
@@ -214,3 +230,12 @@ Include repository, branch, commit SHA, changed paths, commands, local results,
- [ ] Contradictions were escalated, not guessed through.
- [ ] Ways of Working and Engineering documentation remains accurate.
- [ ] Completed work includes exact evidence.
## Canonical naming and compatibility
- Canonical installed and repository name: `channel-delivery-skic`.
- Source: `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/channel-delivery-skic`.
- Previous name: `corp-v1-channel-delivery`; retained locally only as a compatibility alias. New guidance and presentations use the canonical name.
- Naming-only migration authorized by RootAtSkic in [presentation message 1562523679223578705](https://discord.com/channels/1518726359512387766/1543922127898415154/1562523679223578705). Repository ID, history, support files, project authority and organization ownership are preserved.
- This is a reusable central reference, not a new shared Discord channel. Project adoptions use `channel-delivery-skic-<code>` and remain separately owned.
- Current project channel: `<code>-delivery` inside `skic-<code>`.
+30
View File
@@ -0,0 +1,30 @@
# Naming Delivery review
## Outcome
Applied the seven requested canonical skill-identity bindings only inside the two assigned Delivery source packages. Operational entry/reference loads and routing tests use canonical names. AeroSim retains exactly **18 direct dependencies**; central Delivery retains its original **12**. Compatibility aliases are not added as owners. Completed responsibility consolidation and all retained gate, recovery, worker, storage, UAT and authority clauses remain intact.
## Preservation and evidence
- Original checksum manifests were not edited or regenerated. Golden comparisons reverse only the explicit seven identity substitutions before matching protected clauses/checksums; original hashes remain authoritative.
- Added exact dependency-list/count/uniqueness tests against Git HEAD, reversible mapping tests, negative policy-mutation checks, and operational legacy-load detection. Generic Discord tags, runtime workspace/environment names and provenance URLs are not normalized.
- Historical SIMPLIFICATION/ADOPTION records and legacy source URLs remain unchanged as provenance. Canonical repository publication is the parent's work; this local review does not invent new repository URLs or claim publication of those pending owner packages.
- FULL-PROGRAM.md now cites Piotras Board approval plainly at message `1563064779772526616`. Its acceptance update records parent-reported GitOps canonical+alias+generic-base install/skill_view verification at `7ceb741c5fecbe34eb06e10a72e3ae26e3cc6f14`, plus merged/installed gates `02e716ddff053c71a921839419ed2bd2334f1e67`, integrity `3ca0fbb284b5eb194ad5ff1f2756f1fde0077c6a`, TTD `d3d91be7bb2926b0f1bd16db60c0fe2250ed8d39` and wave `a180018ef3bc337bb1fbabd095fa7a4e13471fc5`.
- `corp-v1-glossary` identity/source unchanged: public-to-private transfer needs a decision. **A02/A04 remain unresolved and require a human choice.** A17 bounded resumption-evidence gap remains unchanged.
## Executed local verification
Using `/opt/hermes/.venv/bin/python` with each package's standalone `verify_full_program.py`:
| Package | unittest | standalone functions/main | total | local links | diff check |
|---|---:|---:|---:|---:|---|
| channel-delivery-skic | 22 | 3 | 25 | 29 | passed |
| channel-delivery-skic-aerosim | 32 | 4 | 36 | 36 | passed |
Central operational content: 80,924 HEAD baseline → 76,535 bytes; AeroSim: 105,884 → 104,686 bytes. These retain consolidation reductions despite longer canonical names.
## Changed files / limits
Both packages: SKILL.md, FULL-PROGRAM.md, runtime-and-ci.md, affected routing/semantic tests, golden-comparison tests and standalone verifier import setup. AeroSim additionally: planning-artifact-reconciliation.md, failure-and-documentation.md and gitea-actions-policy.md. Added `canonical_identity.py` and `test_canonical_identity.py` under each existing harness directory, and this review report.
Existing worktree modifications were preserved. No commit, push, install, scheduler/account operation or runtime write occurred. No owner publication performed here. Initial local mapping regex was corrected before verification; all final standalone harness checks pass. No unresolved local test failures.
+30
View File
@@ -0,0 +1,30 @@
# AeroSim lessons review — Delivery
## Immutable sources
AeroSim Delivery source SHA: `0c0e68bde3189fd96415af6035200cf7fcb9c877`. Central baseline: `0bf71b905f0160631460807b371732b1afc5b0cb`.
- [SKILL.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/SKILL.md)
- [references/task-delivery-gates.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/references/task-delivery-gates.md)
- [references/runtime-and-ci.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/references/runtime-and-ci.md)
- [references/single-subagent-task-delivery.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/references/single-subagent-task-delivery.md)
Read the full source skill and all nine references against the central skill and its seven references. Relevant sections: **Overview**, **End-to-End Task Delivery Gates**, **Hourly Worker Reconciliation**, gate **Stage 5**, **Immutable application images and Helm charts**, and **Main-Session Verification**.
## Promoted lessons
- Bind the post-integration UAT handoff to an actual deployed tuple, not a PR-head CI result or image push. Put the contract in Stage 5, without duplicating generic exact-head algorithms already owned by `development-gates`.
- Distinguish root Git, child chart/source, pod image, and endpoint identity; operational health is not user-visible acceptance.
- Retain destination delivery proof and prevent a Releases notification from bypassing UAT or authorizing release.
- Include UAT in the information boundary; replace stale seven-channel wording rather than retaining two conflicting lists.
## Runtime drift reviewed
Installed Delivery `SKILL.md` SHA-256: `46e5304d701d180496688d9a16bb1413fb96c7a888aaf83570da62fc8a7447ff`; installed `references/task-delivery-gates.md` SHA-256: `fcb02322d5f440f3e59a24fa03c4ae74370e469aa6a35a42d94db8818448cca0`. These are supplementary local snapshots, not content attributed to the pinned Git commit. Their **End-to-End Task Delivery Gates / Stage 5** strengthen runtime readback and non-runtime `not_applicable` reasons. Generalized only the ready-for-UAT evidence requirement; the universal AeroSim development-deployment mandate and its standing authority remain project-local. Full runtime reference diffs were inspected, including stale test-ownership wording.
## Exclusions
No project rollout, runtime overwrite, owner reassignment, branch naming change, Jira mandate, standing merge/deploy delegation, account recovery, board/channel IDs, endpoint, scheduler cadence, or deployment configuration is promoted. Central authority and project overlays remain unchanged. The newer central functional-non-unit versus build-time artifact-validation split is retained; runtime references that send Helm artifact validation to UAT are stale and are not imported.
## Verification
Run `python3 -B -m unittest discover -s tests -v` from this repository, plus `git diff --check`. Tests validate the published documentation contract and links offline; they do not prove a deployment or live acceptance run.
+21
View File
@@ -0,0 +1,21 @@
# the adopted project Delivery Pitfalls
Load this reference when a gate fails, when work resumes after interruption, or before reporting a blocker, CI result, merge, or completion.
Before execution, load [runtime-and-ci.md](runtime-and-ci.md#execution-context-toolchain-preflight) for exact-context preflight. Before claims, load `development-gates` and `development-integrity`, then [status-and-reporting.md](status-and-reporting.md) and [planning-artifact-reconciliation.md](planning-artifact-reconciliation.md) for project formatting, semantic reconciliation and duplicate suppression.
## Common Pitfalls
1. Patching symptoms before understanding root cause.
2. Changing requirements or architecture implicitly through code.
3. Editing without loading applicable project engineering skills.
4. Skipping tests for behavioral fixes.
5. Updating documentation with aspirational rather than actual practice.
6. Inspecting another project.
7. Starting implementation because requirements exist but human implementation approval is absent.
8. Ignoring architecture task dependencies, the Task's `READY_FOR_DELIVERY` handoff, or target-version allocation.
9. Posting passive status when safe implementation, testing, diagnosis, or documentation work is available.
10. Treating a human-merged planning or Architecture documentation PR as implementation approval.
11. Treating an ideation-board entry, generated presentation, or broad approval as equivalent to an exact Task `READY_FOR_DELIVERY` transition—or requiring a second admission after that verified transition.
12. Editing in a local-only worktree or on a differently named local branch before the exact remote branch and PR head are visible and verified.
13. Stopping at a repairable gate failure, abandoning the active Task, or starting another Task instead of fixing forward and rerunning the gate until it passes.
+56
View File
@@ -0,0 +1,56 @@
# the adopted project Failure and Documentation Operations
Load this reference when repairing a failure or changing Delivery-owned project documentation.
## Failure-Repair Workflow
When a build or CI failure is observed:
1. verify repository, linked branch and PR, exact failed command/file/test/job, failure class, and exact logs;
2. reproduce locally when feasible;
3. determine root cause before editing;
4. compare the intended fix against approved FR/NFRs, ADRs, architecture documentation, and project conventions;
5. load `development-method-ttd` and [runtime-and-ci.md — Unit testing](runtime-and-ci.md#unit-testing); observe the product-reason unit failure before behavior changes;
6. implement the smallest safe forward fix, preserving valid shared work and missing-RED honesty;
7. run local validation;
8. commit and push through the approved branch workflow;
9. inspect CI for the exact new head SHA;
10. report evidence and remaining risk;
11. repeat diagnosis, repair, and affected validation until the active gate passes.
The skill must continue with a safe forward fix when the failure and expected behavior are clear. A repairable failure does not end the Task or authorize moving to another gate or Task. If evidence is insufficient, requirements/architecture conflict, an external dependency is unavailable, or the required action exceeds authority, keep the Task in the same gate, record the separate blocker with evidence and owner, and raise the issue in the relevant channel:
- requirement/product ambiguity → `general` and/or `architecture` as appropriate;
- architecture contradiction → `architecture`;
- release policy/readiness ambiguity → `releases`;
- implementation-only blocker → `delivery`.
Never guess the team's intended direction, weaken a gate, or treat a blocker as a passed gate. Resume the same gate and continue the repair loop when the blocker is removed.
## Documentation Ownership
Before authoring or validating documentation, load `documentation-docusaurus` from [the global source](https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus) and the project-adopted documentation overlay for Diátaxis, Markdown/MDX, navigation and build mechanics. Verify source identity: an unrelated same-name installation is not this global owner. Before defining reusable terms, load `corp-v1-glossary` from [its source](https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1-glossary); it owns canonical definitions in the final top-level Glossary and domain-page links. If the required owner cannot be loaded, stop the affected documentation action.
Delivery retains these domain outcomes in two areas:
### Ways of Working — five sections
1. **Delivery workflow** — intake, prioritization, implementation states, and definition of done.
2. **Branching and reviews** — branch conventions, pull requests, approvals, and merge expectations.
3. **Planning and ownership** — backlog, sequencing, owners, dependencies, blockers, and escalation.
4. **Quality practices** — review standards, test strategy, defect handling, and evidence expectations.
5. **Collaboration and decisions** — channel routing, handoffs, decision references, and communication norms.
### Engineering — five sections
1. **Repository and workspace** — monorepo/application/package structure and local prerequisites.
2. **Development and unit testing** — commands, unit-test fixtures, debugging, Delivery artifact validation, and the handoff to UAT for every functional non-unit suite.
3. **Build and continuous integration** — pipelines, checks, artifacts, runners, and failure diagnosis.
4. **Packaging and deployment preparation** — containers, Helm/GitOps interfaces, configuration, and release inputs.
5. **Operations and troubleshooting** — observability, known failure modes, recovery checks, and evidence collection.
Update these pages from verified project practice. Do not document a planned process as already operational.
## Synchronization Workflow
Before reconciling planning/Architecture/Kanban changes, load [planning-artifact-reconciliation.md](planning-artifact-reconciliation.md) for Task-row semantics and its verification-owner loads. Use the entry skill's synchronization/iteration contract for useful safe work and current documentation. Reconcile only changed evidence; do not duplicate its workflow here.
@@ -0,0 +1,38 @@
# Planning-artifact reconciliation
Use when planning or readiness documentation changes while implementation remains gated.
## Verification owners — load at the decision point
Before verifying a PR or CI, run `skill_view(name="development-gates")` and load its `references/review-ci-merge-contract.md`: **Evidence model**, **Attempt integrity**, and **Concurrent publication** own candidate/remote equality, complete successful job inventory including aggregates, and separate integration evidence. Do not use a successful listed-task subset as a gate.
Before reporting, load `skill_view(name="development-integrity")` and its `references/remote-checkpoint-matrix.md` for the current remote checkpoint, changed-head invalidation and candidate-versus-integration claims; then load [status-and-reporting.md](status-and-reporting.md) for Delivery formatting. Preserve project reviewer/merge authority; A02/A04 review-order/base-drift remain bounded unresolved clauses, not implicitly settled by these loads.
Before validation, load `documentation-docusaurus` and the project-adopted overlay through [Documentation Ownership](failure-and-documentation.md#documentation-ownership); verify source identity. Run the complete repository validator and production build with frozen-lockfile installation and `git diff --check`. The global owner identity mismatch remains unresolved: retain the bounded nested-pnpm fallback below, not an assumed replacement owner.
If child scripts cannot find pnpm, use `corepack enable --install-directory <cache>/pnpm-bin`, prepend that temporary shim directory to `PATH`, and rerun the declared command. Keep shim/dependency caches outside commits and verify the worktree remains clean.
## Retained validation bindings
- Use the fresh PR API `head.ref` and full SHA, never a title or old report, for a clean detached worktree inside the Task boundary. Assert its actual HEAD and process working directory before repository-native validation. These exact-worktree checks remain local until the installed owner carries them.
- If the PR merged or closed during validation, update its reported state and validate the freshly resolved merge/default head, including semantic probes. Use the owners above for fresh evidence immediately before reporting; repeat if it changes. Keep API task `id`, `run_number`, run/attempt/job IDs and UI URLs distinct in retained evidence.
## Delivery interpretation
Read current same-project activity and distinguish human decisions from agent reports. Verify changed artifacts by authenticated readback at the validated revision and inspect their **semantics**: the exact Task row and status, evidence timestamp, new head/task pairs and absence of superseded pairs when reconciliation claims their removal. Parse lifecycle sections separately; headings, keyword counts and generated presentations are not Task-state evidence. If a probe disagrees with rendered Markdown, inspect numbered lines and correct the probe before reporting.
New pickup requires current `READY_FOR_DELIVERY`, dependencies, target version, parent Feature implementation approval and FR/NFR/ADR/UI/UX readiness under the preserved project authority. That status already records admission: no second Focus-admission decision. Continuation instead requires current `IN_PROGRESS`, its existing claim and historical verified admission; do not demand re-admission or mistake historical portfolio status for current Task authority. A merged Board page does not itself admit a Task. If the gate remains closed, do not create application changes; verify or reconcile documentation or route the evidenced blocker instead.
## Evidence interpretation
| Evidence | What it proves | What it does not prove |
|---|---|---|
| Documentation PR merged by a human | The reviewed documentation landed | Feature implementation approval |
| Architecture hierarchy/validator passes | Documentation structure meets its contract | A proposed Feature has an accepted solution |
| Kanban Board lists an item in ideation | The unfinished scope record is visible | Exact Task `READY_FOR_DELIVERY` handoff |
| Documentation CI succeeds | That documentation head passed its checks | Application CI or release readiness |
| Application baseline CI succeeds | The observed application head is healthy | A new Task PR, deployment, or release |
## Avoid duplicate status
Before posting, compare the proposed report with enough Delivery history to find the newest marker, head SHA, CI task, and blocker set. If there is no new human decision, repository head, CI result, actionable failure, or durable documentation change, return the configured silent response instead of restating the same gate.
@@ -0,0 +1,59 @@
# the adopted project Repository Entry and Visibility
Load this reference before claiming a Task, creating its application branch, opening its PR, or resuming its worktree.
All local repository entry happens inside `<code>-delivery/workspace/<TASK_ID>/`. During preparation, create only the required repository clones: `application/` and `documentation/`. Optional Task-local `review/`, `cache/`, `tmp/`, `logs/`, or `artifacts/` folders may be added later only when a concrete Task activity needs them. Reusable installed toolchains and technical dependencies are the sole exception: place them in `<code>-delivery/cache/`, never in a Task workspace. A repository branch, clone, Task evidence file, or other Task-local support folder outside the selected Task directory does not satisfy this gate.
## Implementation Entry Gate
Before claiming a Task for Feature implementation, verify in project documentation:
- Feature ID and parent Epic;
- exact `Approved for Implementation` evidence from the primary Architecture owner `the active project authority` or the active project authority as backup;
- linked FRs/NFRs and accepted solution/ADR context;
- task breakdown and dependencies;
- target version and status;
- acceptance evidence expected from delivery;
- exact Task `READY_FOR_DELIVERY` evidence, which itself records Focus admission by the active project authority; and
- an approved UI/UX package from the active UI/UX authority or the active project authority as backup when the task changes user-facing design.
Delivery must verify the Feature decision and exact Task `READY_FOR_DELIVERY` state before initial coding, then claim the Task by moving it directly to `IN_PROGRESS`. Continue claimed work in `IN_PROGRESS` while retaining the original handoff evidence. Do not require a second Focus admission after `READY_FOR_DELIVERY` or infer missing evidence from broad delegation, silence, CI, a Board wave, or a planning status. When a record is absent, route the exact owning action to Scope, Architecture, or Kanban rather than creating an out-of-scope lifecycle or flow mutation inside an implementation change.
## Immediate Wave-Start Visibility Gate
Before any implementation or repository content change begins on a newly claimed the adopted project Task, establish and verify all of these Gitea checkpoints:
1. Create the dedicated local branch with the required Task branch name, create an empty kickoff commit if needed, and push that exact branch immediately.
2. Open a visible pull request from that exact branch to `test` before editing a repository file. Do not wait for implementation, tests, review, or a finished diff.
3. Put the Task ID, wave, planned scope, and current Task state in the PR so the active project authority and the team can monitor progress from the beginning.
4. Read the PR and remote ref back, then prove that the local branch name exactly equals the remote branch and PR head ref, the local kickoff commit equals the remote branch head, and the PR base is `test`.
5. Only after the remote branch and visible pull request already exist and all identities match may Delivery edit tests, source, configuration, documentation, or other repository content.
No repository file may be edited before this gate passes. A differently named local convenience branch that merely tracks the PR branch does not pass, because it hides the branch identity during status reporting and makes accidental publication to the wrong ref easier. When resuming an existing worktree, fetch the PR head explicitly, require the current local branch name to equal the PR head ref, and fast-forward before editing; if the names differ, repair the local branch identity without force-pushing or creating a competing PR.
One Task requires one dedicated branch and one visible PR unless the adopted project Architecture or the active project authority explicitly approves a different grouping. Do not hide several independently deliverable Tasks behind a shared wave branch. If Gitea refuses a no-diff PR, create and push an empty kickoff commit—never a filler file change—then open the PR. A locally created worktree, unpushed branch, compare URL, or push without PR readback does not satisfy this gate.
### Branch and pull-request naming contract
For every the adopted project delivery Task, use this exact source-branch shape:
```text
<release>/<TASK_ID>-<short-explanation>-<attempt-digit>
```
Example:
```text
0.1.0/TASK-0049-persist-simulation-metadata-1
```
- `<release>` is the Task's exact target release, without a leading `v`. Do not derive it from a package manifest, invent it, or replace it with `unreleased`, `next`, or a wave label.
- `<TASK_ID>` is the exact Task ID, preserving its uppercase spelling.
- `<short-explanation>` is a concise lowercase ASCII kebab-case description (`a-z`, `0-9`, and single hyphens only).
- `<attempt-digit>` is an unpadded positive decimal attempt number. Start at `1`; increment it only when a new branch/PR attempt is required. Never reuse an attempt number for the same release, Task, and explanation.
- The complete branch must pass `git check-ref-format --branch`, contain exactly one `/`, and remain a valid Gitea branch ref. Spaces, repeated separators, `..`, `@{`, backslash, control characters, and the Git-forbidden characters `~ ^ : ? * [` are not allowed.
- Resolve collisions against freshly fetched local and remote refs before creating the branch. Never force-push or repurpose an earlier attempt.
The Gitea pull-request title must exactly equal the source branch name. Gitea's PR API treats the title as a string rather than a Git ref, but using the exact branch value provides one unambiguous release/Task/attempt identity across the branch list, PR list, API, CI, and evidence records. Do not prepend `feat:`, `fix:`, an emoji, a wave label, or other prose to the title.
Before creating the PR, verify the Gitea technical prerequisites: the source branch is pushed, the base branch is exactly `test`, head and base differ, the branch contains a commit not already in `test`, and no open PR already exists for the same head/base pair. Create the PR with explicit `title`, `head`, `base`, and `body` fields. The body must record the Task ID, release, attempt, wave, planned scope, Task state, validation plan, and requirement/ADR links. Read the PR back and require exact title, head ref/SHA, and `test` base; a compare URL or successful API response alone is not evidence that the PR contract is satisfied.
+84
View File
@@ -0,0 +1,84 @@
# the adopted project Runtime and CI
Load this reference before login, toolchain execution, CI work, image publication, or Gondor resource work.
## Channel-owned workspace
Resolve the channel root as `<code>-delivery/` under the active user's working root:
```text
<code>-delivery/
├── cache/ # reusable channel toolchains and technical dependencies
├── uploads/
└── workspace/
└── <TASK_ID>/
├── application/ # always: repository clone
├── documentation/ # always: repository clone
├── review/ # optional: only when separate review files are needed
├── cache/ # optional: only when a Task-specific cache is needed
├── tmp/ # optional: only when temporary Task files are needed
├── logs/ # optional: only when logs must be retained
└── artifacts/ # optional: only when outputs must be retained
```
- `cache/` contains reusable technical dependencies installed by Delivery, including pinned Node/pnpm toolchains, Nginx binaries, and package-manager download caches. Browser/Playwright dependencies for non-unit suites belong to the UAT workspace and E2E repository. Reuse verified entries across Tasks instead of reinstalling them. Version or digest cache paths when compatibility matters, verify the resolved executable and version in every execution context, and never store credentials, Task evidence, repository content, or mutable application state there.
- `uploads/` contains files supplied through this channel. It is not a repository checkout or build directory.
- Create one `workspace/<TASK_ID>/` directory per Task.
- During `GATE_001_PREP`, create only the required repository clones: `application/` and `documentation/`. If a Task genuinely needs another repository, clone it as another clearly named child.
- Do not create Task-local `review/`, `cache/`, `tmp/`, `logs/`, or `artifacts/` speculatively. Create each folder only when a concrete activity for that Task needs it.
- Use Task-local `review/` only for a separate review checkout or review output. Use Task-local `cache/` only for non-reusable data bound to that Task; reusable installed technical dependencies belong in the channel-level `cache/`. Use `tmp/`, `logs/`, and `artifacts/` only for their named Task-local purpose.
- Run dependency installation, generation, tests, and builds inside the applicable repository clone using that repository's normal paths. Copy or export outputs to `artifacts/` only when they must be retained separately.
- Keep every optional folder inside the selected Task directory. Never share it between Tasks or place it at the channel root.
- Before every local repository command, resolve the real working directory and require it to be inside the selected Task directory. A command running elsewhere is invalid evidence and must stop before mutation.
- Do not reuse another Task's clone or support folder as a shortcut. Resume only from the selected Task's own workspace after fetching and matching its visible PR head.
## Shared Corp v1 System Login
Before login, load `channel-board-skic` and follow its complete **Corp v1 System SSO Credential Use** policy through [Delivery's source/authority binding](../SKILL.md#shared-corp-v1-system-login). Stop if unavailable; secret access grants no additional authority.
## Delivery Responsibilities
### Coding
Load `development-monorepo-pnpm` for pnpm/TypeScript implementation and `development-scripts` for Taskfile, shell, environment and Devbox work, using their [source links and project-overlay precedence](../SKILL.md#development-skill-routing). Preserve project structure/namespace; implement only approved Features and authorized Tasks with small, traceable changes, no unrelated refactors and no fabricated results.
### Unit testing
Load `development-method-ttd` before every behavior change, defect fix or refactor. Follow its mandatory failing-test-first unit workflow and retain real commands/results; request non-unit coverage from UAT. Exceptions require the authorized project owner explicitly approving a documented exception. Discard/start-over applies only to the executor's isolated, unpublished experimental delta, preserving unrelated or valid work. Never rewrite shared history, delete another worker's changes or revert integrated work. Repair shared/integrated code forward, record historical missing RED honestly and never claim retrospective tests proved test-first compliance; seek the named project-authority exception if compliant repair cannot satisfy the gate.
### Build and continuous integration
Use [Delivery's build/CI responsibilities](../SKILL.md#build-and-continuous-integration) for the required failure classes and UAT remediation boundary. Before reporting CI, load `development-integrity` through [status-and-reporting.md](status-and-reporting.md); a local build is not remote CI evidence. Task gate job inventory and exact-head checks still apply.
### Execution-context toolchain preflight
Immediately before every repository operation, load `skill_view(name="development-scripts", file_path="references/runtime-preflight.md")` for exact-context checks and repair, plus `skill_view(name="development-monorepo-pnpm", file_path="references/workspace-and-tooling.md")` for committed versions. Load `development-scripts` for the selected repository's script overlay; generic mechanics never replace project authority.
Treat every foreground shell, detached worktree, background process, worker, Hermes main-session review command, and CI job as a separate execution context. Complete the applicable preflight in that exact context before execution; the full owner procedure is mandatory for a Node/pnpm repository or any command that may invoke Node or pnpm. Stop on failed preflight or an unavailable owner; do not run the original command until its complete preflight passes.
Delivery supplies the selected Task directory, selected repository, expected branch/PR/revision, required non-secret environment names under `CORP_V1_<CODE>_*`, and allowed command scope. Preserve Task/cache isolation and real-CWD containment above. Preflight does not authorize resource-dependent tests, functional non-unit suites, credentials, Devbox execution or deployment; the existing project boundary decides allowed operations. Narrow local checks never replace complete repository CI, all required jobs/aggregates or exact-head evidence in [Task gates](task-delivery-gates.md).
Before Delivery publication/install or operational adoption, verify the published and installed owner reference covers the mapped safeguards and record its immutable owner revision and reference hash. The adopted immutable owner revisions and reference hashes are recorded in FULL-PROGRAM.md and the owner-consolidation manifest; a sibling source checkout is not installed-owner evidence. If that gate is unresolved, stop adoption rather than silently weakening preflight. See [FULL-PROGRAM.md](../FULL-PROGRAM.md#final-bounded-owner-consolidation) for inspected evidence.
### Per-project reusable CI base images
the adopted project owns `corp-v1-<code>/corp-v1-<code>-base-images` as the reusable CI-image repository. Use it when stable runtimes or operating-system tools would otherwise be downloaded repeatedly in application jobs.
Before creating, validating, publishing, consuming or repairing a base image, load `skill_view(name="devsecops-ci-cd-gitea", file_path="references/base-images.md")`, then its `references/pipeline-workflow.md` and `references/harbor-auth.md` trust/credential contracts. The owner carries construction, credential-free candidate validation, immutable publication/readback, fail-closed regressions and consumer verification mechanics. Stop if unavailable; retain all project-specific image requirements rather than replacing them with generic defaults.
- Publish only from the trusted `test` branch of the selected project base-image repository; candidate checks remain credential-free. The global owner's configurable branch does not change this binding.
- Consume the directly verified immutable digest in project workflows, never `latest`, a mutable tag or an unverified local name. Keep the first real Gitea build, Harbor publication, digest readback and consumer workflow at the exact PR-head SHA as separate Delivery evidence layers.
- Runtime smoke and published-digest runtime acceptance belong to UAT, separately from Delivery static/unit validation. No publication or consumer success implies deployment or UAT acceptance.
- Repair image or publication failures forward only. Preserve the last known-good digest for consumers until the replacement image and consuming workflow pass exact-head CI and applicable UAT acceptance.
Owner adoption evidence: global CI source `669e28eadfe79ac7cb3c10ccdea318dd5296d481`; inspected source and installed `references/base-images.md` are byte-identical (SHA-256 `1fb0e24ec5789b195be9ae35fbb9529fa1cab56112dae5baf9455284ca490e53`). Its `owner-responsibility.json` maps both Delivery contracts. Reverify the complete published owner package and project CI overlay at adoption; this is owner-policy evidence, not a consumer build, publication or runtime result.
### Gondor runtime-resource placement
The adopted project CI jobs and developer workstations must not provision PostgreSQL, queues, object stores, caches, brokers, or other application runtime services. Load `development-gitops-argo-cd-home-gondor-v1` before defining or changing Gondor desired state. Render the committed project template separately into one repository per environment; Delivery may update only the repository assigned to its non-production environment, while production remains outside Delivery authority unless an explicit project overlay says otherwise.
- Keep every non-production the adopted project environment—including development, integration, test, staging, and preview—and all of its resources isolated from production and from other non-production environments. Destructive or concurrent validation requires a per-run database/schema/role or explicit serialization; it must not reset shared data.
- Delivery CI may orchestrate exact-head unit/build validation, but it must not start application runtime-resource service containers or receive application-resource credentials. Harmless process-local unit-test doubles and build tools are not runtime resources. UAT owns resource-dependent tests and their restricted execution; Delivery only provisions an approved development dependency and hands its exact identity to UAT. Do not expose PostgreSQL or another internal resource through Ingress, NodePort, LoadBalancer, or a runner-accessible public endpoint.
- Before storage design or mutation, load `truenas` and `references/gondor-retained-application-storage.md`. That owner supplies dataset/NFS, retained static PV/PVC and live StorageClass verification; stop if unavailable. Durable storage must not use a deletion-reclaim policy. The load grants no platform authority and does not assert current live storage state.
- Use only External Secrets backed by the existing Bitwarden `ClusterSecretStore`; never commit connection strings or credentials.
- Provision and verify required Gondor resources before deploying dependent the adopted project code. Resource-independent implementation may proceed, but deployment remains blocked until the dependency is healthy and consumed by the application.
+81
View File
@@ -0,0 +1,81 @@
# the adopted project Status and Reporting
Before reporting, load [development-integrity](https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-integrity) for checkpoint claims and implementation-versus-closure evidence. Delivery retains the vocabulary/format below and its existing review, gate, repair/help and scheduler boundaries; this load resolves none of those policy questions.
## Scope Status Vocabulary
Before reporting or changing any lifecycle status, read the project's current `ways-of-working/scope.md`. Use only the values defined there.
Ideas, Epics, and Features:
```text
IN_BACKLOG → IN_DESIGN → READY_FOR_DELIVERY → IN_DELIVERY → TO_BE_RELEASED → DONE
```
Tasks:
```text
IN_BACKLOG → READY_FOR_DELIVERY → IN_PROGRESS → TO_BE_RELEASED → DONE
```
`READY_FOR_DELIVERY` is the exact Task's Focus-admitted, pickup-ready state. It means Architecture, dependencies, implementation boundaries, verification steps, and Kanban selection are complete; implementation has not started. Delivery claims that Task by moving it directly to `IN_PROGRESS`. Never require or invent a second Focus-admission decision after `READY_FOR_DELIVERY`.
`CANCELLED` is an exceptional terminal status. `BLOCKED` is a separate flag with a reason and evidence; it never replaces the lifecycle status.
Never invent, abbreviate, or substitute lifecycle values such as `Ready`, `Active`, `Delivered`, `Complete`, `Awaiting CI`, or `Overrun`. Those phrases may describe activity only when clearly separated from the status field. If the status cannot be verified, report `status unverified` and inspect the source record rather than guessing.
A merge or successful CI does not automatically mean `DONE`. Releasable application Tasks normally move from `IN_PROGRESS` to `TO_BE_RELEASED`; `DONE` requires the applicable release or completion evidence. Status reports must show the exact value even when a separate plain-language action is also included.
## Wave Status Report
When the active project authority explicitly asks for project, delivery, blocker, progress, or wave status, begin the status report with this exact first-line structure, with no text before it:
```text
wave-previous: <previous wave> | wave-current: <current wave> | wave-next: <next wave>
```
Each value must be an actual dependency-wave label calculated by the the adopted project Release Task Board, such as `Wave 11`, `Wave 12`, or `Wave 13`. Never substitute activities, work descriptions, statuses, invented phases, or ad hoc labels. Resolve the current wave and its adjacent existing waves from the Board selector and task assignments; do not infer them from conversation wording. Use `none` only when the Board has no previous or next wave.
Do not repeat the wave header or task chapter in ordinary acknowledgements, implementation narration, questions, or non-status replies. Use them only when the active project authority explicitly asks for status.
### Current-wave task chapter
Immediately after the header in a requested status report, include:
```text
## Wave XX (Current)
- TASK-XXXX — <status> — Responsible: <Hermes main session or concrete owning process>
```
Replace `XX` with the current Board wave number. List every Task assigned to that wave—never a sample or only changed Tasks—and use each Task's verified flow status. For responsibility, name Hermes main session when it actively owns the Task; otherwise name the concrete owning process, such as Delivery pickup, implementation/review, integration, or Release handoff. When no active executor or owning process exists, say `Unassigned`; never invent an agent, process, or ownership. Refresh the Board/task records and live process state before reporting when they may have changed.
### Human-facing delivery updates
In every implementation, review, CI, blocker, merge, handoff, or completion update, lead with the linked branch and pull request where the work is visible. The next line must identify the Task, exact Task status, active gate code, and gate title:
```text
<TASK_ID> | <TASK_STATUS> | <GATE_CODE> — <GATE_TITLE>
```
Example:
```text
TASK-0084 | IN_PROGRESS | GATE_003_TASK_IMPLEMENTATION — Implement and Review the Task
```
While work remains inside a gate, continue reporting that same code. When its exit gate passes, report the transition explicitly:
```text
GATE_003_TASK_IMPLEMENTATION passed → GATE_004_TASK_PR_CI
```
When blocked, name the gate where progress stopped:
```text
BLOCKED at GATE_004_TASK_PR_CI — Verify and Merge the Task PR
```
Do not invent a separate phase or shorthand. Do not lead with or routinely include commit SHAs, tree hashes, digests, internal worktree paths, or temporary review-commit identities; retain those for automated verification and provide them only when the active project authority asks for audit detail or when an identity mismatch itself is the blocker.
When anything fails, identify the exact failed command, file, test, or CI job. State its failure classification—application code, test assertion, workflow, infrastructure, credentials, or local execution environment—then provide the expected behavior and observed behavior, whether repository or remote state changed, and the concrete repair or owner. Never summarize a failure as only “validation failed”, “review failed”, or “CI failed”.
+111
View File
@@ -0,0 +1,111 @@
# the adopted project Task Delivery Gates
This file contains the ordered Delivery overlay for delivering one the adopted project Task. Load it before selecting or continuing a Task.
Before candidate review, CI, merge or integration verification, run `skill_view(name="development-gates")` and load `references/review-ci-merge-contract.md`. Its Evidence model and Attempt integrity own immutable identities, complete required job/aggregate inventory, one successful attempt and separate integration evidence. Use those mechanics at each stage; retain the local exit outcomes and reviewer/authority bindings below. Missing owner guidance blocks the affected gate.
**Bounded unresolved A02/A04:** substantive push/review order and “base drift is harmless” remain recorded local clauses pending the separate exact resolution. This consolidation does not choose between them and the reusable owner's ordering/base rule. Do not treat the load as approval of a new exception; route an affected conflict before acting.
## End-to-End Task Delivery Gates
These gates are mandatory and ordered. Each `GATE_###_NAME` code is the stable identifier used in communication and evidence. Hermes must not skip ahead, combine evidence from different revisions, or start the next Task before `GATE_005_TASK_POST_MERGE` passes. The three repositories used by this process are:
- application: `corp-v1-<code>/corp-v1-<code>`;
- Task files and project documentation: `corp-v1-<code>/corp-v1-<code>-documentation`; and
- this Delivery skill: `corp-v1-<code>-skills-code-agent/channel-delivery-skic-<code>`.
Before repository entry, load [repository-entry-and-visibility.md](repository-entry-and-visibility.md) for the complete entry/branch/visibility contract and [runtime-and-ci.md](runtime-and-ci.md#channel-owned-workspace) for required clones, optional directories, reusable cache and Task isolation. These remain mandatory gate inputs, not optional background reading.
Hermes main session owns the Task, performs implementation and exact-head review, and communicates with the active project authority. Local repository tools execute deterministic commands. Gitea Actions runs remote CI. Gondor/GitOps is used only by an approved deployment or Release process. Cron never owns or continues a Task. No implementation or review subagent may work on the selected Task.
Verification is part of each stage, not a separate end checklist. Before leaving a stage, pass its **Exit gate** and retain the evidence named there. Every Delivery progress, blocker, CI, merge, handoff, and completion update must name the active gate code and title. When a gate passes, report the passed gate code and the next gate code. At every stage, use only the adopted project's eight project channels, load the references and engineering skills required for that action, route contradictions instead of guessing, and report failures with the exact command, file, test, or CI job.
### Mandatory gate-failure recovery
Before repairing any failed check/review/CI/publication/exit condition, load [Failure-Repair Workflow](failure-and-documentation.md#failure-repair-workflow). It owns diagnosis, scope-safe forward repair, affected revalidation, blocker evidence and routing. Remain in the same gate until its complete exit passes; never weaken or relabel a failed gate. Pause only for its external-dependency, credential, decision, authority or safety blocker, recording `BLOCKED` separately without changing lifecycle status. Resume the same gate when removed.
### Stage 1 — `GATE_001_PREP` — Pick, Start, and Open the Task PR
**Repository and branch:** Read documentation remote `test` before branching. Establish fresh `application/` and `documentation/` clones inside the selected Task workspace under the loaded entry contract. Application branch: `<release>/<TASK_ID>-<short-explanation>-<attempt>`; documentation claim branch: `<release>/<TASK_ID>-start-delivery-<attempt>`. Each PR title equals its branch and targets `test`.
**Runtime:** Hermes main session verifies eligibility, creates and reads back the application branch and PR without editing repository content, then creates the documentation branch and PR, updates the Task file, runs documentation checks, and merges the documentation PR only after its checks pass. Gitea Actions runs remote checks. Do not use HermesSubAgent or cron.
**Required work:** Apply the loaded entry contract to exactly one current-wave `READY_FOR_DELIVERY` Task: Feature approval, dependencies, Architecture/requirements, target release and UI/UX readiness. Inspect only the adopted project’s eight channels. Establish and read back the application branch/PR before any edit. In the Task’s documentation clone add the hash-linked `READY_FOR_DELIVERY` to `IN_PROGRESS` event with actor, time, Task, wave, branch/PR evidence, previous hash and new hash; validate/review/merge it.
**Exit gate:** Loaded workspace and entry checks pass: required Task-local clones have expected remotes, optional folders have a concrete need, and application branch/PR identity is verified. Documentation claim is merged and remote Task state is `IN_PROGRESS`. Only then edit repository content. Report Task, wave, dependencies, PR, workspace and merged claim. Missing or contradictory eligibility blocks selection, mutation and branch creation; name the owner.
### Stage 2 — `GATE_002_TASK_PLAN` — Plan the Task
**Repository and branch:** Read Task, requirement, Architecture, and UI/UX files from the Task's `documentation/` clone at `test`; keep implementation notes and changes in the Task's `application/` clone on the existing application Task branch.
**Runtime:** Hermes main session inspects documentation and application code. Do not use HermesSubAgent.
**Required work:** Load the project engineering skills needed by the Task. Map each acceptance criterion to affected production code, a named test, edge and failure cases, security boundaries, build or artifact evidence, and its requirement or Architecture reference.
**Exit gate:** Every criterion has a checkable proof. A contradiction stops implementation and goes to the responsible Scope, Architecture, UI/UX, Kanban, or Release owner.
### Stage 3 — `GATE_003_TASK_IMPLEMENTATION` — Implement and Review the Task
**Repository and branch:** Use `<code>-delivery/workspace/<TASK_ID>/application/` on the existing application Task branch and PR. Application source, unit tests, configuration, application-documentation changes, builds, and image/container/Helm artifact validation stay in that clone and branch. Every functional non-unit suite stays in the UAT-owned E2E repository. If a separate review checkout or output is needed, create and use `review/` under the same Task directory.
**Runtime:** Main session implements and reviews inside the selected Task workspace. Load runtime preflight before every execution context and create optional folders only for concrete needs. No implementation/review subagent, human-review dependency or cron.
**Required work:**
1. Load [runtime-and-ci.md](runtime-and-ci.md#execution-context-toolchain-preflight) and pass its exact-context preflight inside the selected Task workspace before commands. Unit tests use process-local fakes, not runtime services; UAT owns resource-dependent testing.
2. Load `development-method-ttd` and follow mandatory failing-unit-test-first TTD for defects, new behavior and refactors; only an explicitly approved documented exception from the authorized project owner permits departure. Request non-unit coverage from UAT. Tooling, environment and credential failures are not product-test evidence.
3. Implement only the approved Task, one behavior slice at a time. Keep the diff small, cover normal, edge, and failure behavior, avoid unrelated refactors, and repair forward without reverting valid work.
4. Run all applicable focused and full unit tests, lint, format checks, typecheck or compile, production build, production dependency audit, static checks, generated-artifact checks, and Delivery-owned Dockerfile/image/container/publication/Helm artifact validations, plus `git diff --check` and repository-state checks. Do not run functional integration, browser, security-boundary, performance, or acceptance suites in Delivery; request and consume those results from UAT.
5. After local checks pass, commit and push the Task changes without rewriting history. Read back the remote branch and PR and verify that the local checked revision, remote branch head, and PR head are identical.
6. Hermes main session reviews that exact PR head for logic, security, acceptance coverage, production-path use, and test gaps. Tests alone are not the review. The main session must inspect the complete diff and relevant production paths, record a pass/fail verdict for the exact revision, and remain accountable for that verdict. If review finds a problem, remain in `GATE_003_TASK_IMPLEMENTATION`: repair it on the same Task branch, rerun affected local checks, push the new PR head, and review that exact head again.
**Exit gate:** Task-workspace/preflight rules and all local checks pass; every acceptance criterion has implementation/test evidence; `development-gates` candidate identity matches remote branch/PR and exact-head review has no unresolved finding. Later edits keep/return the Task to `GATE_003_TASK_IMPLEMENTATION` until affected checks, push/readback and review pass. Failure reports use [status-and-reporting.md](status-and-reporting.md): exact command/file/test/finding, observed versus expected behavior, failure class, mutation state and repair/owner.
### Stage 4 — `GATE_004_TASK_PR_CI` — Verify and Merge the Task PR
**Repository and branch:** Use the application PR and `application/` clone inside the selected Task workspace, targeting `corp-v1-<code>/corp-v1-<code>` `test`; then fetch and read the resulting application `test` revision in that same clone after merge.
**Runtime:** Gitea Actions runs PR CI. Hermes main session verifies CI and PR state, confirms its own exact-head review still covers the PR head, performs the authorized Gitea merge, and reads back the merge result. No subagent reviews or merges.
**Required work:**
1. Apply the loaded `development-gates` attempt-integrity contract to all required Delivery jobs: unit tests, lint, typecheck, build, static security and artifact validation, including the required aggregate.
2. Immediately before merge, re-read the PR and current application `test`. Confirm that the PR remains open, its head is unchanged, its base is `test`, its branch equals the reviewed PR head, required CI is green, review still matches, the PR is mergeable, and base drift is harmless.
3. If conflict resolution, rebase, or any file/tree change is required, return to `GATE_003_TASK_IMPLEMENTATION`; repeat affected local checks, push/readback, and review for the new PR head; then restart `GATE_004_TASK_PR_CI` for that exact head.
4. Apply the loaded owner’s reviewed-head merge and separate integration readback contract within existing merge authority.
**Exit gate:** All required PR CI succeeds on the exact reviewed PR head; the final pre-merge check refers to that same head; the PR is merged; and the exact application `test` integration revision is known. The Task remains `IN_PROGRESS`; merge alone does not mean `TO_BE_RELEASED` or `DONE`.
### Stage 5 — `GATE_005_TASK_POST_MERGE` — Verify Integration and Hand Off the Task
**Repository and branch:** Use the selected Task's `application/` clone to validate `corp-v1-<code>/corp-v1-<code>` `test` at the exact integration revision produced by `GATE_004_TASK_PR_CI`. Then use the same Task's `documentation/` clone to create branch `<release>/<TASK_ID>-release-handoff-<attempt>` into documentation `test`, with a PR title exactly equal to the branch name and base `test`.
**Runtime:** Gitea Actions runs application integration, build, publication, and documentation checks. Hermes main session verifies those results, creates and validates the documentation handoff, applies the review rules from `GATE_003_TASK_IMPLEMENTATION` to the exact documentation PR head, and performs the authorized documentation merge. Gondor/GitOps is used only within approved deployment authority. Apply the deployment and handoff evidence contract below before declaring the handoff complete.
**Required work:**
1. Apply the loaded owner’s separate integration gate to all required application unit/build, container, immutable publication and artifact checks. Retain registry digest readback; PR-head CI cannot replace integration evidence.
2. Complete the deployment and handoff evidence contract below, then add the hash-linked `IN_PROGRESS` to `TO_BE_RELEASED` event with the merged application PR, integration revision, successful integration CI, publication and deployment evidence when required, and the UAT handoff or verified non-runtime exception.
3. Update Ways of Working or Engineering documentation only when this Task changed how the project actually works.
4. Validate, review, merge, and read back the documentation handoff PR.
**Exit gate:** Every required post-merge unit-test, build, and publication job succeeds on the exact application `test` revision; the documentation PR is merged; and the Task file on remote documentation `test` says `TO_BE_RELEASED`. The deployment and handoff evidence contract below must also pass. Only then may Delivery call the Task delivered. Release execution and the later `DONE` transition belong to `channel-releases-skic-<code>`, not this Delivery process.
#### Deployment and handoff evidence
For runtime-affecting work using Delivery → UAT, require a verified non-production deployment before a ready-for-UAT handoff. Resolve the approved deployment owner, target environment, and desired-state repository from the project contract; this requirement grants no deployment authority. Missing authority or deployment evidence is `BLOCKED`, not a successful handoff. If the project requires deployment before `TO_BE_RELEASED`, enforce that gate even when the Task omits it. Only work with no deployable runtime effect may record `not_applicable`, with a verified reason; lack of permission is not such a reason.
Retain the exact integrated application commit, immutable image digests and chart identity where applicable, template provenance, rendered GitOps commit, controller revisions/sync/health, pod image IDs, environment/base URL, verification time, Task identity, and limitations. Follow the owning GitOps workflow, not direct workload mutation. For app-of-apps, distinguish root Git revision from child chart/source revision and verify each against its own desired state. Deployment readback proves identity and operational health, not user-visible acceptance; UAT owns that verdict.
Send the frozen packet to the mapped UAT channel and any release-readiness notification required by the adopted workflow. Retain the destination channel/message ID and readback, or the verified dispatcher delivery receipt; a source-channel mention is not delivery proof. Respect auto-delivery contracts rather than sending duplicate messages, and report delivery as unverified until a receipt exists. A Releases notification routes readiness only; it neither skips UAT nor authorizes release or `DONE`.
### Stage 6 — `GATE_006_NEXT_TASK` — Pick the Next Task
**Repository and branch:** Read refreshed documentation `test` and the Board from the completed Task's `documentation/` clone. Do not reuse that Task directory for another Task and create no new branch until the next Task passes `GATE_001_PREP`, which creates its own workspace and fresh clones.
**Runtime:** Hermes main session selects the next Task. Do not use cron or a subagent for selection.
**Required work:** Confirm the previous Task says `TO_BE_RELEASED`, no delivery blocker remains, capacity is free, and the next Task says `READY_FOR_DELIVERY` with satisfied dependencies.
**Exit gate:** Report the next selected Task and return to `GATE_001_PREP`. Do not wait for `DONE`; release execution and `DONE` are owned by `channel-releases-skic-<code>`.
+26
View File
@@ -0,0 +1,26 @@
"""Exact, reversible skill-identity migration; never rewrite provenance URLs."""
import re
IDENTITIES = {
'development-branching-strategy-aerosim': 'development-branching-strategy-skic-aerosim',
'development-scripts-aerosim': 'development-scripts-skic-aerosim',
'devsecops-ci-cd-gitea-aerosim': 'devsecops-ci-cd-gitea-skic-aerosim',
'documentation-docusaurus-aerosim': 'documentation-docusaurus-skic-aerosim',
'development-gitops-argo-cd-gondor-v1': 'development-gitops-argo-cd-home-gondor-v1',
'home-v1-discord': 'discord',
'home-v1--truenas': 'truenas',
}
def translate(text, mapping):
# Bare discord/truenas are common words: only migrate explicit skill identity
# delimiters (inline code, quoted names, and related_skills list entries).
pattern = r'(?P<left>`|[\"\'])(?P<name>' + '|'.join(map(re.escape, mapping)) + r')(?=[`\"\'\],])'
text = re.sub(pattern, lambda m: m['left'] + mapping[m['name']], text)
return re.sub(r'(?m)^( related_skills: \[)(.*)(\])$',
lambda m: m[1] + ', '.join(mapping.get(v, v) for v in m[2].split(', ')) + m[3], text)
def canonicalize(text):
return translate(text, IDENTITIES)
def original_identity(text):
return translate(text, {new: old for old, new in IDENTITIES.items()})
+77
View File
@@ -0,0 +1,77 @@
[
{
"path": "references/task-delivery-gates.md",
"pattern": "^5\\. After local checks pass,.*$",
"hashes": [
"e4e6ae6f894fdb0b5dc1779b7037c39eb476ee80620f93a253c4a68ea4adabd1"
]
},
{
"path": "references/task-delivery-gates.md",
"pattern": "^6\\. (?:The active executor|Hermes main session) reviews.*$",
"hashes": [
"63acb91e7391daac3af378032e4842ef7da6d03ff1f1939016180f9fffb5f86c"
]
},
{
"path": "references/task-delivery-gates.md",
"pattern": "^2\\. Immediately before merge,.*$",
"hashes": [
"fb6968a7bea4662e945ca914c53988cc1d9d72b02681384f7041a89ad347c229"
]
},
{
"path": "references/task-delivery-gates.md",
"pattern": "^3\\. If conflict resolution,.*$",
"hashes": [
"6052be5ba307b088499acdc0abcecbea36719695f423e6e9b888027d85867e89"
]
},
{
"path": "references/task-delivery-gates.md",
"pattern": "^\\*\\*Exit gate:\\*\\* All required PR CI.*$",
"hashes": [
"ff18fe3b523dae671eb14f513e1f90700eeea9c8a93bf85686f67b8f9635e7f3"
]
},
{
"path": "references/task-delivery-gates.md",
"pattern": "^\\*\\*Exit gate:\\*\\* Every required post-merge.*$",
"hashes": [
"9338b15f03aa46139240842a0c72c92fd3af2d91e1af4ee82c55fe859361d196"
]
},
{
"path": "references/task-delivery-gates.md",
"pattern": "^### Stage [1-6].*$",
"hashes": [
"50a5e09da6aca1488d9d375c22740b39c0168837bde39bb390352186f7982d6d",
"fc758ac75b342cceb555b927710c0aba38ca31fd6bdbca4eb7ed054f814c2f38",
"f68e0313b622ef7666bccd0c6bd9551153e01e2b8f6cc68978a4dda72924c45a",
"156eb690576a1a812c3fb7d32ee32fb98c174c81143830a336ca4ec54dd27745",
"4a76eda13fa68c5f28b458d5d1ad400211c4daad5418b3f3319c36b84ade03b2",
"960be6948de8a23e4591cfa099c9cf30e47f2b1b72f8702f05c6d7dd1713bfd7"
]
},
{
"path": "references/status-and-reporting.md",
"pattern": "(?s)## Scope Status Vocabulary.*",
"hashes": [
"0aa256d5852c664c0d18b3888990d6c31e73a4e50e894324e1d11cb72a970b93"
]
},
{
"path": "references/failure-and-documentation.md",
"pattern": "(?s)When a build or CI failure is observed:.*?(?=5\\. )",
"hashes": [
"d7850a4ca34226dd9b45badc1623012e87a2557f3cced4b63807939be00a72f5"
]
},
{
"path": "references/failure-and-documentation.md",
"pattern": "(?s)7\\. run local validation;.*?(?=## Documentation Ownership)",
"hashes": [
"13e74d3dd90a757a7a7d0ef7f0a4448cb6a7764b7c63ce8699b40f197fbac6fa"
]
}
]
+97
View File
@@ -0,0 +1,97 @@
{
"owners": {
"preflight": {
"owner": "development-scripts",
"reference": "references/runtime-preflight.md",
"source_url": "https://gitea.lego-cloud.eu/global-skills/development-scripts",
"inspected_head": "0e36552938da94c0539e39b35256b8effe34c25d",
"sha256": "07306382b8afe5c2d2e83e2955a04a1523d008e7e39cead7c7a1797bb6640462",
"state": "merged source and installed reference byte-identical; authenticated immutable full-package readback verified",
"evidence_text": "# Exact-context toolchain preflight\n\nUse before repository commands in a Node/pnpm repository, or any command that may invoke Node or pnpm. This is a reusable execution procedure, not a project directory convention or permission to run tests. The caller supplies the authorized repository, revision, worker context, required environment names and permitted operation. Task-directory containment and stop-on-failed-preflight remain caller responsibilities.\n\n## Required inputs\n\nLoad `development-monorepo-pnpm` and its `references/workspace-and-tooling.md` tooling reference for version selection and committed toolchain/workspace conventions. Resolve required Node and pnpm versions from the repository's **committed toolchain contract**, not ambient executables. Inspect the selected revision's package-manager pin, Node declaration and applicable locked environment/image metadata. Do not invent a universal version or workspace layout. If declarations conflict, are absent, or leave the required exact version unresolved, stop and reconcile the contract with its owner before running the requested command. A version range alone is not an exact observed-version pin.\n\n## Procedure\n\nTreat every foreground shell, detached worktree, background process, main-session review command and CI job as a separate execution context. A successful check elsewhere is not transferable evidence. Perform inspection/preflight in the intended context before the requested repository operation; inspection commands themselves are necessary to establish the context.\n\n1. Resolve the required versions from the committed toolchain contract at the expected source revision. Record the paths/revision used, not secret content.\n2. Inside that exact shell/process/container run `command -v node`, `node --version`, `command -v pnpm`, and `pnpm --version`, using `terminal` or the equivalent job step. Require every command to succeed; compare observed versions to the resolved required versions (normalize only Node's leading `v`). An executable found in a different shell is not sufficient. Record executable paths and observed/required versions.\n3. Verify required non-secret environment variable names are present, including disposable-test database markers when applicable, **without reading or printing their values**. For Bash, a presence-only `[[ -v VARIABLE_NAME ]]` check is suitable after validating a supplied name against `[A-Za-z_][A-Za-z0-9_]*`. Do not dump `env`, expand indirect values, enable tracing, or read credentials. Presence alone does not prove resource isolation or authorize database use; that remains the caller's separate gate.\n4. Verify the actual working directory and repository root; compare source HEAD and linked branch/PR identity with caller-supplied expected identity. Inspect repository state and confirm it is clean or intentionally staged, with every intentional change accounted for. Detached HEAD is allowed only when it matches the authorized revision/worktree. Never reset/stash unrelated changes to make a check green. Do not assume a project-specific application layout.\n5. Start the original command only after every applicable check passes. Keep activation, verification and execution in the same context. Recheck if PATH, activation, working directory, revision, image or required environment changes. A background worker must do its own preflight within its launch command, not consume a foreground success flag.\n\n## Failure and repair\n\nNever assume a background process inherits `PATH`, shell activation, Devbox state, Corepack activation, database variables or other exports from a foreground terminal. Missing `pnpm` is an execution-context/toolchain failure, **never an application-code or test failure**. Missing Node, wrong versions, wrong working directory/revision and absent required names also block execution; they do not constitute product RED.\n\nRepair the exact context by providing the required toolchain path or approved activation. Do not silently install a latest toolchain, rewrite pins, or execute Devbox unless the parent workflow permits it. Then **repeat the complete preflight** there and rerun the original command before making a claim about repository code. Preserve failure and rerun evidence separately.\n\n## Verification and scope\n\nRecord expected/observed versions, executable paths, repository root/revision, branch/PR link, approved state, presence-only results, context identity and command outcome. Do not include secrets or environment values. Local narrow validation never replaces all-app CI or exact-head remote job evidence. Toolchain success is not a claim of CI, publication, deployment or runtime acceptance.\n\nRun the owner contract regression with `terminal(command=\"python3 scripts/test_preflight_contract.py\", workdir=\"<skill-repository>\")`. This checks maintained guidance, not a live consumer toolchain; the five steps above must still be exercised for each real conLine truncated
},
"base_images": {
"owner": "devsecops-ci-cd-gitea",
"reference": "references/base-images.md",
"source_url": "https://gitea.lego-cloud.eu/global-skills/devsecops-ci-cd-gitea",
"inspected_head": "669e28eadfe79ac7cb3c10ccdea318dd5296d481",
"sha256": "1fb0e24ec5789b195be9ae35fbb9529fa1cab56112dae5baf9455284ca490e53",
"state": "merged source and installed reference byte-identical; authenticated immutable full-package readback verified",
"evidence_text": "# Reusable CI base-image contract\n\nUse when stable runtimes or OS tools would otherwise be downloaded repeatedly in application jobs. This owner defines reusable construction, validation, publication and consumption mechanics; it does not choose a project's image repository, branch, application layout or runtime-smoke authority. Supply those bindings from the project Delivery/CI overlay. Runtime verification is a separate acceptance layer delegated to the project's authorized runtime-test owner, not permission granted by this reference.\n\nRead [pipeline-workflow.md](pipeline-workflow.md) for trust boundaries, exact checkout and immutable retries, and [harbor-auth.md](harbor-auth.md) for credential handling. These safeguards apply in addition to this contract; base-image work is not an exemption.\n\n## Construction and static contract\n\n1. Keep one folder per image containing a Dockerfile, machine-readable version/platform metadata, usage documentation, a build helper and a static publication contract. Record required upstream reference, platforms, runtime/tool pins, numeric user/group and supported workspace path. Do not prescribe a product's application directories.\n2. Pin the upstream base by digest (`repository@sha256:<64 lowercase hexadecimal characters>`). Check the actual resolved platform against metadata; for a multi-platform index, record index and platform-manifest relationships rather than silently comparing unlike digests.\n3. Assert exact runtime/tool versions, architecture, numeric non-root identity, writable workspace, CA trust, Git, shell and every other required tool. Static/unit checks inspect Dockerfile and metadata; they cannot alone prove live writability, effective UID, trust or executable behavior. The authorized runtime verifier must exercise those assertions on the **published digest** and record results separately. Never describe a static declaration as runtime proof.\n4. Prefer the verified job image over repeated `actions/setup-node` or package-manager bootstrap steps. Keep `pnpm install --frozen-lockfile --ignore-scripts` in the application repository for lockfile parity; do not bake project dependencies or credentials into a generic base image. This does not waive the consumer's committed toolchain contract or exact-context preflight in `development-scripts/references/runtime-preflight.md`.\n\n## Candidate isolation and trusted publication\n\n- Build and perform static/unit validation on pull requests **without registry credentials**. Credential absence must be structural: no publication secret in workflow-global scope, candidate job environment, persistent runner home, Docker config, build args, cache or artifact. Skipping login does not remove an already available credential. Use an approved credential-free base acquisition path; if unavailable, stop rather than leak publication credentials to candidates.\n- Choose exactly one configured default integration branch, as in the pipeline owner (`test` or `main`), and publish only its exact trusted integration commit. PR, fork, branch-readiness and broad tag triggers cannot publish. Separately authorized release workflows must retain equivalent isolation, never broaden the ordinary candidate path.\n- Complete candidate execution before introducing a narrowly scoped Harbor robot secret in the isolated trusted publication job. Pass secrets via standard input only. Keep temporary Docker/Helm credential stores scoped to the job, clean on success and failure, and treat logout failure on persistent runners as failure after cleanup. Never pre-seed push credentials into the reusable job image or execute untrusted candidate hooks after authentication.\n\n## Immutable publication and direct readback\n\n1. Verify checkout identity before building. Tag the image with the full 40-character source revision; never publish `latest`, mutable version aliases or shortened SHAs for governed consumption. Enforce registry immutable-tag rules as well as workflow checks.\n2. Preserve the validated local image ID. Existing tags are reusable only when the remote OCI config digest equals that validated local image ID; different content is a hard failure, not an overwrite. For multiple platforms, verify each required platform's config identity and expected manifest/index membership. Missing or ambiguous remote evidence fails closed.\n3. After publication, read back the Harbor artifact directly: verify reference, source identity, platform and manifest digest. Record source URL/revision, workflow run/attempt/job, immutable tag, manifest digest, config digest/local image ID and canonical millisecond ISO-8601 UTC timestamp. Config digest is for retry content comparison; manifest digest is for consumption. Do not interchange either with source SHA or chart archive checksum.\n4. Require the final aggregate under `always()` to explicitly require every necessary build/publication/readback job's success. A green push step or skipped aggrLine truncated
}
},
"moved_clauses": [
{
"clause": "version resolution, executable/version comparisons",
"owner_key": "preflight",
"section": "Required inputs; Procedure 1\u20132"
},
{
"clause": "presence-only environment and repository identity/state checks",
"owner_key": "preflight",
"section": "Procedure 3\u20134"
},
{
"clause": "same-context activation, inheritance failure classification and complete retry",
"owner_key": "preflight",
"section": "Procedure 5; Failure and repair"
},
{
"clause": "image folder/metadata, digest/tool/platform/user/workspace/trust assertions and lockfile parity",
"owner_key": "base_images",
"section": "Construction and static contract"
},
{
"clause": "credential-free candidates and isolated trusted publication",
"owner_key": "base_images",
"section": "Candidate isolation and trusted publication"
},
{
"clause": "full-source tags, direct Harbor readback, immutable retry and aggregates",
"owner_key": "base_images",
"section": "Immutable publication and direct readback"
},
{
"clause": "digest consumer verification and forward repair mechanics",
"owner_key": "base_images",
"section": "Consumer verification and forward repair"
},
{
"clause": "negative trigger/tag/secret/interpolation/digest/setup regression cases",
"owner_key": "base_images",
"section": "Fail-closed regression matrix"
}
],
"retained_local": [
"every foreground shell",
"detached worktree",
"background process",
"worker",
"Hermes main-session review command",
"CI job",
"Stop on failed preflight",
"selected Task directory",
"selected repository",
"allowed command scope",
"complete repository CI",
"last known-good digest",
"trusted `test` branch",
"UAT",
"exact PR-head SHA"
],
"superseded_golden_rules": [
{
"path": "references/runtime-and-ci.md",
"pattern": "(?s)### Per-project reusable CI base images\\n.*?(?=### Gondor)",
"hashes": [
"0c92e0521c57c357a62c8313c70527547427d98b7647ec8cd1a97c148b5ba4f1"
]
},
{
"path": "references/runtime-and-ci.md",
"pattern": "(?s)Treat every foreground shell.*?(?=### Immutable|### Per-project)",
"hashes": [
"8df9d2e952a6a8c48fd3d0a18357aea21d5ffbb1e06e53c7273c6e50e2545be5"
]
}
]
}
+57
View File
@@ -0,0 +1,57 @@
"""Offline regression tests for the channel's published prose contract."""
from pathlib import Path
import re
import unittest
ROOT = Path(__file__).resolve().parents[1]
class LessonsContract(unittest.TestCase):
def test_review_provenance_and_link(self):
review = ROOT / "references/aerosim-lessons-review.md"
self.assertTrue(review.is_file())
text = review.read_text()
self.assertRegex(text, r"/src/commit/[0-9a-f]{40}/")
self.assertIn("## Exclusions", text)
self.assertIn("aerosim-lessons-review.md", (ROOT / "SKILL.md").read_text())
def test_local_markdown_links_resolve(self):
for path in [ROOT / "SKILL.md", *ROOT.glob("references/*.md")]:
for target in re.findall(r"\]\(([^)]+)\)", path.read_text()):
if "://" not in target and not target.startswith(("#", "<")):
self.assertTrue((path.parent / target.split("#")[0]).is_file(), (path, target))
def test_no_project_authority_transplant(self):
for path in [ROOT / "SKILL.md", *ROOT.glob("references/*.md")]:
if path.name == "aerosim-lessons-review.md":
continue
text = path.read_text()
for forbidden in ("jarvis-at-skic", "aerosim-dev.apps", "AEROSIM_STANDING", "1537388451501056081"):
self.assertNotIn(forbidden, text)
def test_contract_0(self):
text = (ROOT / 'references/task-delivery-gates.md').read_text()
self.assertIn('#### Deployment and handoff evidence', text)
self.assertIn('pod image IDs', text)
self.assertIn('destination channel/message ID', text)
self.assertIn('not_applicable', text)
self.assertIn('not user-visible acceptance', text)
def test_contract_1(self):
text = (ROOT / 'SKILL.md').read_text()
self.assertIn('<code>-uat', text)
self.assertIn('version: 1.15.0', text)
def test_stage_five_scope_and_authority(self):
text = (ROOT / "references/task-delivery-gates.md").read_text()
stage = text.split("### Stage 5", 1)[1].split("### Stage 6", 1)[0]
self.assertIn("#### Deployment and handoff evidence", stage)
self.assertNotRegex(stage, r"(?m)^## ")
self.assertIn("this requirement grants no deployment authority", stage)
self.assertIn("If the project requires deployment before", stage)
self.assertNotIn("only if the Task explicitly includes", stage)
self.assertIn("image/container/Helm artifact validation", text)
self.assertIn("No implementation or review subagent", text)
if __name__ == "__main__":
unittest.main()
+47
View File
@@ -0,0 +1,47 @@
"""Canonical bindings preserve owners and original checksum sensitivity."""
from pathlib import Path
import hashlib
import re
import subprocess
import unittest
from canonical_identity import IDENTITIES, canonicalize, original_identity
ROOT = Path(__file__).resolve().parents[1]
class CanonicalIdentity(unittest.TestCase):
def test_exact_identity_and_dependency_count(self):
current = (ROOT / 'SKILL.md').read_text()
baseline = subprocess.check_output(['git', 'show', 'HEAD:SKILL.md'], cwd=ROOT, text=True)
def deps(text):
return re.search(r'related_skills: \[(.*?)\]', text)[1].split(', ')
expected = [IDENTITIES.get(v, v) for v in deps(baseline)]
self.assertEqual(deps(current), expected)
self.assertEqual(len(expected), 18 if ROOT.name.endswith('aerosim') else 12)
self.assertEqual(len(set(expected)), len(expected))
self.assertIn('corp-v1-glossary', expected)
self.assertFalse(set(expected) & set(IDENTITIES))
def test_mapping_is_reversible_and_not_a_general_rewrite(self):
self.assertEqual(len(IDENTITIES), len(set(IDENTITIES.values())))
for old, new in IDENTITIES.items():
text = f'Load `{old}`; skill_view(name="{old}"); https://example/{old}; /opt/data/{old}/'
mapped = canonicalize(text)
self.assertIn(f'`{new}`', mapped)
self.assertEqual(original_identity(mapped), text)
text = 'tags: [corp-v1, discord, channel] /opt/data/corp-v1-aerosim-delivery/ gondor-v1-aerosim-dev'
self.assertEqual(original_identity(text), text)
def test_golden_normalization_still_detects_policy_mutation(self):
for old in IDENTITIES:
baseline = f'Load `{old}` before mutation; stop if unavailable.'
canonical = canonicalize(baseline)
digest = lambda t: hashlib.sha256(original_identity(t).encode()).hexdigest()
self.assertEqual(digest(canonical), digest(baseline))
self.assertNotEqual(digest(canonical.replace('stop', 'continue')), digest(baseline))
def test_no_legacy_operational_loads(self):
for path in [ROOT / 'SKILL.md', *ROOT.glob('references/*.md')]:
text = path.read_text()
self.assertEqual(canonicalize(text), text, str(path))
if __name__ == '__main__':
unittest.main()
+34
View File
@@ -0,0 +1,34 @@
from pathlib import Path
ROOT = Path(__file__).resolve().parents[1]
SKILL = (ROOT / "SKILL.md").read_text(encoding="utf-8")
RUNTIME = (ROOT / "references/runtime-and-ci.md").read_text(encoding="utf-8")
REFERENCES = {
"development-durable-wave-execution": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-durable-wave-execution",
"development-gates": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-gates",
"development-integrity": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-integrity",
"development-method-ttd": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-method-ttd",
"development-branching-strategy": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-branching-strategy",
"development-monorepo-pnpm": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-monorepo-pnpm",
"development-scripts": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-scripts",
"development-gitops-argo-cd-home-gondor-v1": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-gitops-argo-cd-gondor-v1",
}
def test_delivery_reference_routes_reusable_development_procedures() -> None:
assert "## Development Skill Routing" in SKILL
for name, url in REFERENCES.items():
assert name in SKILL
assert url in SKILL
def test_generic_automation_is_owned_by_development_scripts() -> None:
assert "`development-scripts` owns Taskfile, `.scripts/`" in SKILL
assert "must not restate generic RED–GREEN–REFACTOR mechanics" in SKILL
assert "the explicit project/channel overlay wins" in SKILL
def test_gitops_reference_requires_one_environment_per_repository() -> None:
assert "development-gitops-argo-cd-home-gondor-v1" in RUNTIME
assert "one repository per environment" in RUNTIME
+55
View File
@@ -0,0 +1,55 @@
"""Full-program consolidation: owner routing and retained policy safeguards."""
from pathlib import Path
import unittest
from canonical_identity import original_identity
ROOT=Path(__file__).resolve().parents[1]
def read(p): return (ROOT/p).read_text()
class FullProgram(unittest.TestCase):
def test_exact_owner_loads_replace_duplicate_algorithms(self):
p=read('references/planning-artifact-reconciliation.md')
for s in ['skill_view(name="development-gates")','skill_view(name="development-integrity")','exact Task row','historical','no second Focus-admission','run_number','head.ref']:
self.assertIn(s,p)
self.assertNotIn('Require each matching task to report',p)
self.assertLess(len(p.encode()),5000)
g=read('references/task-delivery-gates.md')
self.assertIn('skill_view(name="development-gates")',g)
self.assertNotIn('first when practical',g)
self.assertNotIn('seven project channels',g)
self.assertIn('A02/A04',g)
for i in range(1,7): self.assertIn(f'GATE_{i:03}_',g)
def test_storage_and_ttd_decision_loads(self):
r=read('references/runtime-and-ci.md')
self.assertIn('references/gondor-retained-application-storage.md',r)
self.assertIn('before storage design or mutation',r.lower())
self.assertNotIn('before fixing when practical',r)
self.assertIn('development-method-ttd',r)
self.assertIn('isolated, unpublished experimental delta',r)
self.assertIn('historical missing RED',r)
self.assertNotIn('5. implement the smallest safe fix;\n6. add/update tests',read('references/failure-and-documentation.md'))
self.assertIn('last known-good digest',r)
self.assertIn('every foreground shell',r)
def test_clause_disposition_covers_program_without_inventing_resolution(self):
p=read('FULL-PROGRAM.md')
for i in range(1,19): self.assertIn(f'| A{i:02} |',p)
for s in ['1563064779772526616','unresolved','installed','publication','A02','A04','A06','A08','A17']:
self.assertIn(s,p)
def test_original_protected_clauses_remain_exact(self):
import re, json, hashlib
for rule in json.loads((Path(__file__).parent/'full-program-preserved.json').read_text()):
matches=re.findall(rule['pattern'],original_identity(read(rule['path'])),re.M)
self.assertEqual([hashlib.sha256(m.encode()).hexdigest() for m in matches],rule['hashes'],rule['path']+' '+rule['pattern'])
def test_project_specific_boundaries(self):
if not (ROOT/'references/single-subagent-task-delivery.md').exists(): return
w=read('references/single-subagent-task-delivery.md')
self.assertNotIn('│ ├── playwright/',w)
self.assertNotIn('│ ├── postgresql/',w)
self.assertIn('belong to UAT',w)
g=read('references/task-delivery-gates.md')
self.assertIn('per Task',g)
self.assertNotIn('or start the next Task before',g)
c=read('references/gitea-actions-policy.md')
for s in ['skill_view(name="devsecops-ci-cd-gitea-skic-aerosim")','references/pipeline-workflow.md','CI / Branch Readiness','CI / Pull Request Validation','CD / Test Artifact Publication','publication','UAT','all applications']:
self.assertIn(s,c)
self.assertNotIn('## 1. Non-default branch',c)
self.assertLess(len(c.encode()),3200)
if __name__=='__main__': unittest.main()
+39
View File
@@ -0,0 +1,39 @@
"""Moved owner mechanics and retained caller authority, independently runnable."""
from pathlib import Path
import hashlib
import json
import unittest
ROOT = Path(__file__).resolve().parents[1]
class OwnerConsolidation(unittest.TestCase):
def test_owner_evidence_and_clause_mapping(self):
manifest=json.loads((Path(__file__).parent/'owner-consolidation-manifest.json').read_text())
self.assertEqual(len(manifest['superseded_golden_rules']),2)
self.assertEqual(len(manifest['moved_clauses']),8)
for owner in manifest['owners'].values():
self.assertEqual(hashlib.sha256(owner['evidence_text'].encode()).hexdigest(),owner['sha256'])
self.assertEqual(len(owner['inspected_head']),40)
for move in manifest['moved_clauses']:
text=manifest['owners'][move['owner_key']]['evidence_text']
for heading in move['section'].split('; '):
self.assertIn('## '+heading.split(' 1')[0].split(' 3')[0].split(' 5')[0],text)
pre=manifest['owners']['preflight']['evidence_text']
for term in ['command -v node','pnpm --version','without reading or printing their values','linked branch/PR identity','repeat the complete preflight','never an application-code or test failure']:
self.assertIn(term,pre)
base=manifest['owners']['base_images']['evidence_text']
for term in ['without registry credentials','full 40-character source revision','shell interpolation','wrong upstream or consumer digests','pnpm install --frozen-lockfile --ignore-scripts','numeric non-root identity','CA trust','last known-good digest']:
self.assertIn(term,base)
def test_exact_decision_loads_and_local_boundaries(self):
text=(ROOT/'references/runtime-and-ci.md').read_text()
manifest=json.loads((Path(__file__).parent/'owner-consolidation-manifest.json').read_text())
for owner in manifest['owners'].values():
self.assertIn('skill_view(name="'+owner['owner']+'", file_path="'+owner['reference']+'")',text)
for clause in manifest['retained_local']:
self.assertIn(clause,text)
for clause in ['before every repository operation','Node/pnpm repository','CORP_V1_','publication/install','immutable owner revision','forward only','replacement image and consuming workflow pass exact-head CI']:
self.assertIn(clause,text)
self.assertNotIn('neither owner currently replaces',text)
self.assertNotIn('1. resolve the repository-required Node',text)
self.assertNotIn('- Keep one folder per image',text)
repo='corp-v1-aerosim/corp-v1-aerosim-base-images' if ROOT.name.endswith('aerosim') else 'corp-v1-<code>/corp-v1-<code>-base-images'
self.assertIn(repo,text)
if __name__=='__main__': unittest.main()
+54
View File
@@ -0,0 +1,54 @@
"""Offline bounded simplification contract; no dependency or network mutation."""
from pathlib import Path
import hashlib
import unittest
ROOT = Path(__file__).resolve().parents[1]
class SimplificationContract(unittest.TestCase):
def test_retained_safety_sections(self):
for (path, start, end), digest in SECTIONS.items():
text = (ROOT / path).read_text().split(start, 1)[1]
if end:
text = text.split(end, 1)[0]
self.assertEqual(hashlib.sha256(text.encode()).hexdigest(), digest, (path, start))
def test_dependencies_unchanged(self):
self.assertIn(DEPS, (ROOT / 'SKILL.md').read_text())
def test_unresolved_gates_and_safety_files_unchanged(self):
for name, digest in PROTECTED.items():
self.assertEqual(hashlib.sha256((ROOT / name).read_bytes()).hexdigest(), digest, name)
def test_decision_point_loads(self):
for name, markers in {
'SKILL.md': ['Before login, load', 'skic-skills/channel-board-skic', 'version: 1.15.0'],
'references/runtime-and-ci.md': ['Before login, load', 'Load `development-method-ttd`', 'Load `development-monorepo-pnpm`'],
'references/status-and-reporting.md': ['Before reporting, load', 'home-v1-skills-code-agent/development-integrity'],
'references/planning-artifact-reconciliation.md': ['corepack enable --install-directory', 'Before reporting, load'],
'references/failure-and-documentation.md': ['Before authoring or validating documentation, load', 'home-v1-skills-code-agent/corp-v1-glossary'],
}.items():
for marker in markers:
self.assertIn(marker, (ROOT / name).read_text(), (name, marker))
def test_no_helper_or_reference_removed(self):
self.assertEqual({p.name for p in (ROOT / 'references').glob('*.md')}, REFERENCES)
self.assertNotIn('SIMPLIFICATION.md', (ROOT / 'SKILL.md').read_text())
def test_retained_reporting_and_planning_guards(self):
status = (ROOT / 'references/status-and-reporting.md').read_text()
for marker in ['wave-previous:', 'List every Task', 'GATE_003_TASK_IMPLEMENTATION', 'status unverified', 'exact failed command']:
self.assertIn(marker, status)
planning = (ROOT / 'references/planning-artifact-reconciliation.md').read_text()
for marker in ['complete successful job inventory including aggregates', 'run_number', 'semantics', 'If the PR merged or closed', 'no second Focus-admission', 'configured silent response']:
self.assertIn(marker, planning)
def test_operational_size_reduction(self):
paths = [ROOT / 'SKILL.md', *ROOT.glob('references/*.md')]
self.assertLess(sum(len(p.read_bytes()) for p in paths), BASELINE_BYTES)
DEPS = ' related_skills: [channel-board-skic, discord, documentation-docusaurus, corp-v1-glossary, development-durable-wave-execution, development-gates, development-integrity, development-method-ttd, development-branching-strategy, development-monorepo-pnpm, development-scripts, development-gitops-argo-cd-home-gondor-v1]'
PROTECTED = {'references/repository-entry-and-visibility.md': 'f040d6f57c4ec5faf4527296f7f71a751fab2153809e2dbe20c90cf2d582a77d', 'references/aerosim-lessons-review.md': '03873d038f146e28ea648c95f7c2e32d2648d1b5eaa963fb635980fe6e814514'}
REFERENCES = {'task-delivery-gates.md', 'common-pitfalls.md', 'failure-and-documentation.md', 'runtime-and-ci.md', 'repository-entry-and-visibility.md', 'aerosim-lessons-review.md', 'planning-artifact-reconciliation.md', 'status-and-reporting.md'}
SECTIONS = {('references/runtime-and-ci.md', '## Channel-owned workspace', '## Shared Corp'): '48d1e74b737db691ec31ac593400d59abc7d4eed4cd67b2f12f8a428a48034b5', ('SKILL.md', '## Authority and Escalation', '## Evidence Requirements'): 'e3c566055d9d04d3ab0286e6e5035a8c30f66a81b17b4d0379e8010dead3fa83'}
BASELINE_BYTES = 84789
+45
View File
@@ -0,0 +1,45 @@
"""Run every unittest, standalone test function and main-style contract."""
from pathlib import Path
import importlib.util
import inspect
import json
import re
import subprocess
import sys
import unittest
ROOT=Path(__file__).resolve().parents[1]
TESTS=Path(__file__).resolve().parent
sys.path.insert(0, str(TESTS))
suite=unittest.TestSuite()
modules=[]
for path in sorted(TESTS.glob('test_*.py')):
spec=importlib.util.spec_from_file_location('verify_'+path.stem,path)
assert spec is not None and spec.loader is not None
module=importlib.util.module_from_spec(spec)
sys.modules[spec.name]=module
spec.loader.exec_module(module)
modules.append(module)
suite.addTests(unittest.defaultTestLoader.loadTestsFromModule(module))
result=unittest.TextTestRunner(verbosity=1).run(suite)
if not result.wasSuccessful(): sys.exit(1)
standalone=0
for module in modules:
for name,fn in inspect.getmembers(module,inspect.isfunction):
if name.startswith('test_') or name=='main':
fn()
standalone+=1
files=[ROOT/'SKILL.md',*sorted(ROOT.glob('references/*.md'))]
links=0
for path in files:
for link in re.findall(r'\]\(([^)]+)\)',path.read_text()):
if '://' in link or link.startswith(('#','<')): continue
target=link.split('#')[0]
if target:
assert (path.parent/target).exists(),(path,link)
links+=1
subprocess.run(['git','diff','--check'],cwd=ROOT,check=True)
before=sum(len(subprocess.check_output(['git','show','HEAD:'+str(p.relative_to(ROOT))],cwd=ROOT)) for p in files)
after=sum(p.stat().st_size for p in files)
ref_before=before-len(subprocess.check_output(['git','show','HEAD:SKILL.md'],cwd=ROOT))
ref_after=after-(ROOT/'SKILL.md').stat().st_size
print(json.dumps({'package':ROOT.name,'unittest':result.testsRun,'standalone':standalone,'total':result.testsRun+standalone,'local_links':links,'diff_check':'passed','operational_bytes_before':before,'operational_bytes_after':after,'reference_bytes_before':ref_before,'reference_bytes_after':ref_after},indent=2))