107 lines
6.0 KiB
Markdown
107 lines
6.0 KiB
Markdown
# Week of 2026-05-18 → 2026-05-24 (ISO 2026-W21)
|
||||
|
|
|
|||
|
|
_Autonomous PLAN entry — generated by the daily-standup task on 2026-05-18._
|
|||
|
|
|
|||
|
|
## Recap (past 7 days)
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
ec1696f auto(triage): bootstrap label taxonomy, surface unlabeled issue, pair ppap-package
|
|||
|
|
936e446 auto(release): same-day RELEASE re-run — journal-only, no re-tag
|
|||
|
|
766d56f auto(release): v2026.05.W20 weekly snapshot, RELEASES.md, STATUS regen
|
|||
|
|
c4fad8a auto(polish): W20 #5 aspice-assessment-builder pass, regen STATUS.md
|
|||
|
|
49fd9a9 auto(polish): regen STATUS.md and log W20 cs-concept-builder polish findings
|
|||
|
|
5b6ad4e auto(polish): regen STATUS.md and log W20 hara-builder polish findings
|
|||
|
|
16df7a5 auto(plan): W20 targets — hara, cs-concept, aspice-assessment, 8d
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
W20 produced 7 commits: 1 PLAN, 3 POLISH, 2 RELEASE (one was a same-day re-run, no-op
|
|||
|
|
by design), 1 TRIAGE. POLISH targets #3 hara, #4 cs-concept, #5 aspice-assessment
|
|||
|
|
landed; #6 8d-problem-solving did not get a polish pass and carries to W21. Tag
|
|||
|
|
`v2026.05.W20` was cut and `RELEASES.md` opened. The label taxonomy was bootstrapped on
|
|||
|
|
Sunday — all 17 expected labels now exist on the remote, so this week's create-issue
|
|||
|
|
step can route directly to the right buckets. Open-issues count steady at 5.
|
|||
|
|
|
|||
|
|
## Targets for this week (5)
|
|||
|
|
|
|||
|
|
Each target gets a paired GitHub issue (`weekly-target` + domain label) — target 1
|
|||
|
|
reuses the existing open issue #6 rather than duplicating. Definition of Done is the
|
|||
|
|
one-sentence check below; if a target balloons, defer to W22 and record the why.
|
|||
|
|
|
|||
|
|
### 1. `8d-problem-solving-builder.skill` — domain: **quality** (carryover)
|
|||
|
|
- **Why:** W20 carryover. Issue #6 was opened on Monday but the planned POLISH pass
|
|||
|
|
never landed because Tue/Wed/Thu serviced #3/#4/#5. Don't let it slip a second week.
|
|||
|
|
- **DoD:** description names all 8 disciplines (D1–D8) and triggers include "warranty
|
|||
|
|
response," "customer complaint," and "corrective action tracking."
|
|||
|
|
- **Issue:** reuses **#6** (already labeled `weekly-target` + `quality`).
|
|||
|
|
|
|||
|
|
### 2. `dbc-builder.skill` — domain: **comms**
|
|||
|
|
- **Why:** addresses the W20 spread gap (no comms target last week). DBC is the CAN
|
|||
|
|
signal-database backbone every downstream comms artifact (communication-matrix,
|
|||
|
|
bus-load, gateway-routing) is keyed against, so polishing here pays out across the
|
|||
|
|
whole comms cluster (8 builders).
|
|||
|
|
- **DoD:** description trigger list includes "CAN database," "signal definition," "DBC
|
|||
|
|
file," "Vector CANdb," and at least one casual phrasing ("define CAN messages");
|
|||
|
|
description ≤ 1024 chars; frontmatter complete.
|
|||
|
|
|
|||
|
|
### 3. `autosar-swc-builder.skill` — domain: **autosar**
|
|||
|
|
- **Why:** addresses the W20 spread gap (no autosar target last week). Software
|
|||
|
|
Component is the AUTOSAR Classic atomic unit — composition, RTE-mapping, and BSW
|
|||
|
|
builders all consume it, so SWC's I/O contract gates the whole 5-builder autosar
|
|||
|
|
cluster.
|
|||
|
|
- **DoD:** description distinguishes Classic vs Adaptive SWC modeling, port interfaces
|
|||
|
|
(sender-receiver vs client-server) named explicitly, trigger list covers ARXML
|
|||
|
|
output, runnables, and both formal ("AUTOSAR SWC") and casual ("define an AUTOSAR
|
|||
|
|
component") phrasings.
|
|||
|
|
|
|||
|
|
### 4. `uds-services-builder.skill` — domain: **diagnostics**
|
|||
|
|
- **Why:** addresses the W20 spread gap (no diagnostics target last week). UDS is the
|
|||
|
|
ISO 14229 service catalog every downstream diagnostics builder (cdd, odx, dem-config,
|
|||
|
|
dtc-catalog) cross-references. Anchor of the 5-builder diagnostics cluster.
|
|||
|
|
- **DoD:** description names the canonical service IDs (0x10/0x11/0x14/0x19/0x22/0x27/
|
|||
|
|
0x2E/0x31/0x34-0x37/0x3E/0x85), trigger list mentions "UDS," "ISO 14229,"
|
|||
|
|
"diagnostic services," "DID," and "security access"; frontmatter complete.
|
|||
|
|
|
|||
|
|
### 5. Freeze the STATUS classifier — domain: **ci** (tooling, not a skill polish)
|
|||
|
|
- **Why:** three consecutive autonomous-run entries (2026-05-16 RELEASE re-run,
|
|||
|
|
2026-05-16 RELEASE original, 2026-05-17 TRIAGE) have flagged classifier drift
|
|||
|
|
between the spec text and the canonical STATUS body. Today's PLAN regen produced a
|
|||
|
|
zero-domain-label-drift STATUS only because the classifier was hand-tuned to match
|
|||
|
|
yesterday's labels — that's not durable. Land a checked-in script so every future
|
|||
|
|
run reproduces the same labels deterministically.
|
|||
|
|
- **DoD:** `scripts/classify_skill.py` exists, is invoked by the daily run, implements
|
|||
|
|
the spec literally (program-mgmt sub-prefixes before generic `safety-`, sotif before
|
|||
|
|
safety to catch `triggering-conditions-`, quality list is `apqp/dfmea/pfmea/ppap/
|
|||
|
|
control-plan/5-why/8d-/fishbone`, msa-/spc- → other) with an explicit `OVERRIDES`
|
|||
|
|
dict for irregular names; a unit-test-style golden file (`tests/STATUS_golden.md`)
|
|||
|
|
asserts the 76-row output is byte-identical to the W20 canonical STATUS body.
|
|||
|
|
|
|||
|
|
## Domain spread check
|
|||
|
|
|
|||
|
|
| Domain | Count |
|
|||
|
|
|---|---|
|
|||
|
|
| quality | 1 |
|
|||
|
|
| comms | 1 |
|
|||
|
|
| autosar | 1 |
|
|||
|
|
| diagnostics | 1 |
|
|||
|
|
| ci (tooling) | 1 |
|
|||
|
|
|
|||
|
|
Spread is healthy — 4 distinct skill domains plus a tooling target. W21 deliberately
|
|||
|
|
pulls from comms / autosar / diagnostics — the three clusters W20's PLAN flagged as
|
|||
|
|
under-rotated — and keeps quality on the bench only because of the carryover. Notable
|
|||
|
|
gaps still unaddressed this week: **calibration, mbse, sysml, sotif, v&v,
|
|||
|
|
program-mgmt, cyber, safety, aspice**. W22 PLAN should pull from calibration, mbse,
|
|||
|
|
and sysml next to keep the long-tail clusters from going stale.
|
|||
|
|
|
|||
|
|
## Issue links
|
|||
|
|
|
|||
|
|
_Filled in by the create-issue step of this same run; if any cell is blank the API
|
|||
|
|
call failed and the follow-up is captured in the journal._
|
|||
|
|
|
|||
|
|
| Target | Issue |
|
|||
|
|
|---|---|
|
|||
|
|
| 8d-problem-solving-builder | [#6](https://github.com/jherrodthomas/automotive-skills-suite/issues/6) (carryover) |
|
|||
|
|
| dbc-builder | [#7](https://github.com/jherrodthomas/automotive-skills-suite/issues/7) |
|
|||
|
|
| autosar-swc-builder | [#8](https://github.com/jherrodthomas/automotive-skills-suite/issues/8) |
|
|||
|
|
| uds-services-builder | [#9](https://github.com/jherrodthomas/automotive-skills-suite/issues/9) |
|
|||
|
|
| classifier-freeze (scripts/classify_skill.py) | [#10](https://github.com/jherrodthomas/automotive-skills-suite/issues/10) |
|