Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Foundation F: enforce complete journeys in contribution and release

Aperta
  • Qualcosa non va?
#282 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, python, swift
Ambito
devops, release, testing

Direzione di ricerca

Start with the canonical brief in docs/mac-foundation.md, the current evidence in #7, and the acceptance addendum #288; reread the current source before changing anything. Inspect scripts/release/publish_update.py, release.json, and .github/workflows/ci.yml, preserving the existing workflow and release path. Done requires independently required journey coverage and final-artifact-bound evidence, fail-closed validation for missing, stale, malformed, or failing evidence, and the specified real-world acceptance; a schema or green spec alone is not enough.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

The repo already has grammar, surface checks, one CI workflow and one updater, but these do not establish that a complete signed user journey works. Deliver package F of the focused Mac foundation, using #7 as the existing integration/release owner.

Decided scope

  • Put the canonical Value before scope questions into the existing PR template: user outcome/evidence, simpler subtraction/native route, existing owner/useful fallback, total complexity cost and complete acceptance/revisit trigger. Apply them to UI, settings, permissions, updates, CI and marketing. One concise rationale and relevant evidence links suffice for ordinary changes; do not paste the whole policy into every fix or create an approval system.
  • Extend existing harness/gallery checks and source-route audit to test actual admission/callback behavior, retired routes and independently expected failures. Preserve .github/workflows/ci.yml, its classifier, merge-group event and aggregate gate. Add no second quality workflow/dashboard/service.
  • Add a versioned journey acceptance receipt beside release.json, bound to source/channel/build/bundle/final archive hash. Human observation evidence is separate from source/CI. In scripts/release/publish_update.py, reject missing/unknown/stale/failed/not-tested required evidence before external publication.
  • Required scenarios and promoted host/client/route variants come from version-controlled release policy independently of the candidate receipt; the receipt cannot choose its own smaller coverage. Test malformed/stale/missing-variant and deliberately failing cases. Keep reset-completion policy distinct from each independently releasable slice's impact policy. Start with an explicit small requirements list for actual journeys, not a generic host/OS applicability engine.
  • Record the brief's three uncoached outcome tasks and actual native/device/receiver evidence. Before substantial investment/promotion, also establish a real alternative, total correction effort and later voluntary reuse; a one-off working demo is not adoption evidence. Preserve private content; receipts contain only needed environment/results, not transcripts/media/device identifiers.
  • Keep WorkbenchUpdates/Sparkle and one promotion path. Verify old-to-new update, active-work deferral, cancel/failure/relaunch and preserved data. Reuse #271 and coordinate #277 release-lead work.
  • Reconcile exact package/site/handbook claims. Correct signing wording; qualify universal call support, automatic rich-result return, lossless absolutes and setup duration against actual evidence. Narrow unsupported claims instead of labeling failed behavior accepted.

Boundaries and acceptance

The decided coverage addendum #288 extends the merged #278 contract with I1/I2 and Q1–Q3. They are required for the whole-reset claim, with implementation in #287/#15/#165 and the relevant tool owners. A prerequisite or native check may remain pending; it cannot be omitted by reading only the earlier snapshot. #225’s retained correctness repairs belong to A. The delivery lead maintains one package completion checkpoint in #7.

No new release command/orchestrator, telemetry, scheduled cleanup, broad native framework rewrite or count-driven CI deletion. Current parallel CI phases serve distinct purposes; consolidate only proven duplication.

First use #7's existing evidence and exact identity for independently accepted B/C/E or retirement fixes. Exercise one real evidence record, then add the smallest validator and fail-closed fixture cases before claiming the whole reset complete. Do not make new release automation a dependency of the first useful fix. Overall completion requires D1/M1/M2/H1/H2/S1/ST1/P1/P2/R1/U1/U2/I1/I2/Q1/Q2/Q3/X1/X2/X3 and applicable promoted routes under final artifact identity. Read is removed and gets X3 absence/preservation acceptance; Read-only #267 is superseded, not a dependency. Consume relevant #137/#263/#264/#265 evidence without treating unresolved native acceptance as delivered. Review unchanged-path evidence by source/config/environment impact; version number alone cannot transfer acceptance.

A green spec PR, receipt schema or harness cannot close this issue. Actual work-Mac device and receiver limits remain explicit until exercised by an able owner.

Decision and evidence: spec PR #278, canonical brief, research. Baseline is main 7989426; reread current source/issues before implementation.

Implementation map: A #279; B #280; C #281; D existing #63; E existing #276; F #282; G #283; H #284; I #287; J #15 with #165. #7 remains the programme gate.

Lingua principale
Swift
Stelle
0
Fork
1
Merge medio
8h 5m
PR unite (30g)
215

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Ship-Work/workbench

Tutte le issue di Ship-Work/workbench

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.