Preserve AISL email capabilities during Relay migration

Aperta
#30 10 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
18/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
python
Ambito
api, backend

Direzione di ricerca

Read Relay AGENTS.md, docs/PROCESS.md, docs/architecture.md, docs/data-model.md, docs/api.md, and docs/operations.md at commit cdf3a9a25de8bd63af8ee45285983d28a3aa13a0. Then review the AISL capability inventory at f9a3b0432864d40f6f12a85382df4a25c4e3f98f and the linked issues and phase decisions. Done requires owner scope/path acknowledgements and independently accepted preservation evidence for every capability; implementation is currently blocked.

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

Descrizione

Preserve AISL email capabilities during Relay migration

Stage and authority

Groomed preservation parent. Parent #30 remains open until preservation evidence is independently accepted. Existing Relay ui/aisl owners and AISL release owners have not supplied the required scope/path acknowledgements here; implementation affecting their work is blocked.

The owner requires every existing useful AISL email feature to survive, with no visible UI or recipient experience compromise. This includes subject, Markdown formatting, plain text, HTML, chrome, authored footer, verification/unsubscribe actions, operator workflows, and history. No capability retirement, drop or unsolicited redesign is permitted. This parent does not authorize production access, import, sends, deployment, cutover or cleanup.

Read first and process

  • Relay AGENTS.md, docs/PROCESS.md, .claude/agents/product-manager.md, docs/architecture.md, docs/data-model.md, docs/api.md, docs/operations.md, and applicable service/worker contracts at reviewed cdf3a9a25de8bd63af8ee45285983d28a3aa13a0.
  • AISL capability inventory at f9a3b0432864d40f6f12a85382df4a25c4e3f98f, including template/rendering, campaign, SES/event, lifecycle, and operator sources/tests named per donor ID. Source/test references are audit inputs, not executed preservation proof.
  • Community-base phase 6 and decisions D13/D15; A6.1 source-of-truth export, offline A6.1a / AISL #1885, A6.2 contact adoption, A6.3 adapter/rehearsal, A6.4 cutover, and C6.1/C6.2 contraction gates.
  • Existing Relay #22 campaign parity, #25 provisioning, #26 history, #29 footer; AISL #1698 coordinator and reserved #1885/#1851 work.

Committed Relay guidance still uses Datamailer and obsolete tracker/sandbox wording. This work belongs to DataTalksClub/relay; follow its PM → SWE uncommitted implementation → independent Tester → PM acceptance → SWE focused commit → orchestrator/on-call flow. Resolve documentation discrepancies with the Relay owner; do not infer production state from wording or a reachable domain. On-call remains sole CI observer. Use current repository test commands, not website-specific command paths.

Relay at the reviewed commit has no coding-standard.md. The owner nevertheless requires the portable new coding rules across projects: DRY and one business owner, thin handlers, explicit transactions, explicit control flow/no ternaries, simple single-loop comprehensions, functions at most 30 lines and new handwritten files at most 300. Do not grow already oversized files/functions without a documented tool/framework/cohesion constraint accepted during review. A two-field addition is not an automatic waiver. Search existing ownership before extending; use cohesive homes, no arbitrary line-count fragments. Use Relay configuration/test boundaries; do not copy website settings paths. Guidance publication/port is a separate owner task; protected standards remain unchanged.

Goal and architecture

Move generic email storage/versioning/rendering, transport, durable delivery, campaigns, history, and operator capabilities to Relay once independently verified. Keep the minimal AISL business adapter responsible for AISL purposes, live relationship checks, scalar context resolution, greeting/timezone policy, consent projection, and lifecycle triggers. It calls generic Relay/package contracts; it does not retain a second delivery engine or clone donor implementation into Relay.

AISL #1885 owns a normalized versioned offline bundle: dynamic file/override catalog, whole-record subject/body/footer precedence, declared context/preview variants and metadata. Relay validates and consumes that schema; it does not import AISL Python context tables, infer donor files, or implement a second AISL exporter. Offline completion does not establish real override export, Relay adoption or preservation.

Scope and serialized children

The inline proposed child-card table assigns each inventoried donor ID one primary owner and cross-card evidence. Reuse #22/#25/#26/#29 rather than opening duplicate implementations. Proposed new children remain unnumbered until owner review and exact overlap ACKs. Generic and AISL adapter changes use their own repository processes and receipts. No unconditional file/path ownership is granted here.

Required work covers lossless atomic bundle import/footer versions; a generic rendering profile preserving existing output; sender/Reply-To/headers and exact calendar MIME/iTIP support; campaign filters/snapshot/recovery; safe re-permission waves and consent content; subscription/callback projection; lifecycle adapter; schedules; history/identity/diagnostics; operator/staff workflows; owner-operated provisioning and cutover. Absence findings define source audit scope, not permission to remove existing features or ignore ICS/timezones.

Proposed child scope and dependency table

All proposed children remain blocked for implementation pending exact current owner scope/path acknowledgements. Reuse named existing issues, then serialize overlapping edits rather than assuming disjoint paths. Zero runtime or production evidence is implied.

Card Primary owner / existing issue Dependencies / overlap Required scope Verification / receipts Donor IDs
P01 Lossless normalized bundle and footer versions Relay; #29 reused for footer, separate proposed bundle-consumer child AISL #1885/A6.1a schema; #29 grooming; Relay ui/aisl ACK before shared storage/import paths Whole-record metadata/footer drafts/API/immutable snapshot/import parity; full preflight and atomic replay. Relay consumes normalized schema, no donor inference or PREVIEW_CONTEXTS import. Coordinate #29 before implementing importer; one import owner. Override-only key; nonempty-footer unsupported rejection; invalid final item zero changes/queue/network; replay counts and immutable versions; all fields verbatim. T01, T02
P02 Generic rendering profile preserving recipient output Relay generic renderer; AISL policy/context adapter P07 P01 schema/footer; #1885 contexts; Relay ui ACK; AISL rendering owner ACK Generic first-class rendering profile preserves subject/Markdown HTML/plain-text/chrome/footer/actions and preview/send equality. AISL owns greeting/tz/verify policy inputs; no renderer clone. Editor safety and variants align with P10. Dynamic catalog named/nameless, timezone/DST, file/override, verify opt-outs and promo/transactional actions; content-safe render comparison with explicit non-lossy normalizations; edited template safety. T03, T04, T05, T06, T07, A02
P03 Native sender and transport metadata Relay generic transport; #22 campaign sender subsection; #25 actual sender provisioning Relay aisl ACK; #22 sender-path ACK; #25 provisioning separate; AISL event/privacy adapters P07 Client sender policy, valid welcome-only Reply-To omission, CC/BCC/configset, promotional campaign From and donor campaign Reply-To omission. Same body/header HTTPS unsubscribe token, configured mailto and exact one-click header; kill-switch/rate isolation. Native transport delegates exact calendar topology to P15 and outcome certainty to P14; no donor transport clone. Stub SES sender/header payloads; invalid welcome Reply-To omitted; campaign body/header token equality and no campaign Reply-To. Generic optional Reply-To alone is not donor proof. S03, J02, J03
P04 Campaign selection, snapshot, recovery and dispositions Relay #22 expanded/groomed by current campaign owner Relay ui/aisl ACK; P03 sender contract; P09 history Retain tier/tags, Slack/verified tri-state/event scope via generic filters or AISL recipient-list adapter, recount immutable snapshot; locked durable delivery states, failclosed consent, quarantine, maxattempts, recovery retry/assume-sent attribution. No duplicate campaign owner. Campaign test-send retains fixed no-unsubscribe-link preview content, no donor live-history, and does not mint live recipient tracking/unsubscribe tokens. Selection cross-product, stale claims→ambiguous, retry/assume-sent auth/audit, concurrency snapshot/replay and no API send; exact reason/disposition preservation. Safe preview/no-history assertions and recipient body/header HTTPS token equality. K01, K02, K03, K06
P05 Wave release safety and re-permission content Proposed Relay generic gated-wave child of #22; AISL consent policy adapter P07 #22 state ownership ACK; P04/P09; AISL consent owner ACK; P10 wave UI Persist coherent wave monitoring/release attribution as needed; generic configurable gate with AISL100/250/24h and exact donor bounce/current+cumulative rules. Preserve fixed consent block/sole30day CTA and preview/test semantics. No retirement and no forced transactional classification. Preserve durable membership/monitoring-start/release-time/actor/completion/resume through restart; stateless derivation needs equivalence proof. Fixed copy/sole CTA30day token, preview-only URL, persisted-user live-send, unverified-only audience coupling; no action ends marketing, transactional remains. Integer threshold/24h/current+cumulative boundaries; pending/live/failed/ambiguous/expired/no sends/no monitoring/completed block; manual resume no bypass; simultaneous releases no duplicate recipients; consent copy/token expiry. Process restart/release actor/ordered membership and fixed re-permission copy/sole CTA/token expiry/preview and no-action consent result. K04, K05
P06 Consent, subscription and callback projection Relay generic contract where missing; AISL A6.2/C6.2 adapter owner Existing A6.2 accepted scope preserved; new child for missing identity contract, current Relay aisl ACK; P07 and P09 Retain newsletter-only mirror, scoped prefs, optin/no enumeration/throttle/confirm, Maven optout, purge/reminder, hardbounce/complaint and3strike softbounce/diagnostic. Generic callback identity/reconcile contract if needed; no guessed v1 contact identity. Signature/client scope, duplicate/reordered/lost callbacks, pull recovery pagination, softbounce boundaries, newsletter mirror scoped keys unchanged; expiry/returnpath/throttle tests; later owner contacts/runtime receipts. Event-id idempotent three-strike accumulation, hard-bounce/complaint precedence, bounded/redacted diagnostics and send-time suppression. P01, P02, P03, P04, P05, P06, E08, R01
P07 Minimal AISL lifecycle and context adapter AISL new A6.3 child coordinated with #1698/release; package protocol only if missing AISL release/#1885/#1851 path ACK; accepted P01/P02/P03/P06 contracts; #25 for later real adoption Dynamic purpose/producer catalog, domain relations, greeting/tz, classification incl welcome transactional override, footer/consent/link policies, delivery-time token clocks, nonuser/privacy notices. Guard URLs before durable writes, live bindings failclosed, stored hashes unchanged. Use native Relay/package contracts; no second send/render/history engine. Every trigger/purpose positive+stale relation+expiry contract; host/registration keys; no durable rendered/bearer URL; no suppressed recipient log; ICS/payment/download/coursework/member/internal branches; exact existing visible recipient output. C01, C02, C03, C04, S01, S02, L01, L02, L03, L04, L05, L06, L07, L08, G01, G02, G03, G04
P08 Email schedules and durable handler transition AISL A6.3 child; Relay generic jobs owner only contract gaps AISL jobs/release ACK; P07 handlers; existing Relay aisl owner; P12 operational transition Enumerate every declarative schedule/handler and old/new cadence; preserve due/sweep/claim/timeout behavior; no duplicate scheduling backend. No scheduler switch from docs-only preparation. Registry/cadence parity and idempotent sync; disabled/network-free fixtures; duplicate/reordered jobs and expired leases; later owner queued-work drain receipt. J01
P09 History, identity, diagnostics and recovery Relay #26 current history owner; sole old-instance transfer owner retained #25 operational prerequisites; Relay ui/aisl/history-transfer ACK; AISL donor export owner; P06 callbacks Original source IDs/times/provider IDs/order/status/raw provenance and message engagement correlation; aliases/merge continuity/strongest disposition; event metadata and safe operator explain/backfill. One generic import API, no second importer/old-instance rerun. Seven identity states incl conflict/needs reconciliation; primary/alias/log agreement and contradictions failclosed. Never silently merge distinct identities; renamed/merged recipients retain historical snapshots and mixed imported/new chronology; exact complained>bounced>clicked>opened>delivered>sent. 10k synthetic double import zero new/no immutable mutation/no send/callback; client/source collisions, rejects/checksums/counts; alias merge/readback ordering and event recovery; real development-copy equivalence later owner receipt. Alias/primary/log disagreement, seven-state conflict projection, merge+rename continuity without silent contact coalescing. E01, E02, E03, E04, E05, E06, E07
P10 Operator, admin and staff API workflow fidelity Relay ui owner; AISL adapter/navigation child only where needed Relay ui ACK; P01/P02/P04/P05/P09 accepted contracts; AISL Studio owner ACK All donor tasks: editor variants/footer/testsend, log/event filters/details/page/identity/explain, campaign CRUD/audience/recount/recovery/waves/prefill, admin safety/subscriberCSV and scoped staff APIs. Preserve task/permissions/error/empty semantics; no unsolicited design change or copying donor view engine. Existing AISL screens/routes/tasks remain through thin adapters until accepted preservation. No redesign, silent screen removal or route break. Independent rendered donor→target task comparison, auth/filter/paging/detail APIs, no-send API sentinel, test recipient privacy/no donor EmailLog semantics and clearly separate Relay audit; recording prefill and CSV contracts. K07, O01, O02, O03, O04, O05, O06
P11 Provisioning, runtime and readiness receipts Reuse #25 R6.1; approved owner/infrastructure operator only D1.3 D5.2 D13; AISL release ACK; no PM/agent production authority Correct old team wording: transactional/promotional kinds plus welcome transactional From override/validated Reply-To. Reconcile runtime IntegrationSettings/configset/mailto/senders without reading production here; readiness checks remain until accepted equivalent. Actual owner sender/domain/DKIM canary, four-week D13 incident/status evidence, real config/override reconciliation; source or domain existence cannot satisfy. S04
P12 Controlled adoption, fencing, rollback and contraction ledger Existing #1698/A6.1/A6.3/A6.4 owners, aws-infra owner for SES retirement All required preservation children accepted; R6.1/#25, R6.2/#26; AISL release/transfer/ui ACK Durable fence both enqueue/schedulers; classify pending/claimed/ambiguous/provideraccepted sends, drain/transfer/reconcile with stable IDs; revoke old leases; rollback pause Relay and restore only proven unsent intents. Named replacement + receipts for each deletion; no source deletion now. Owner development-copy rehearsal and actual authorized cutover receipts; zero gaps/duplicates and callback/event routing; rollback ambiguous/provideraccepted exercise; no agents production access. Cross-card preservation contract
P13 Evidence completeness, test doubles and bounded absence ledger Parent PM/Tester with relevant repository owners Frozen donor/target and schema revisions; independent Tester role; no source suite execution by PM Keep synthetic SES/job test seams, separate source references from executed evidence, rescan inventory before acceptance. Absence only source-bounded (no AB/future campaigns/i18n/suppression UI/multitenant donor requirement); ICS/timezones remain actual required exceptions. No drop authorization. Every required ID has exact accepted contract and any owner receipt; commit/hash/exits/fresh Tester report; current standards review; no inherited/borrowed CI/adoption proof. S05, A03, A04, A05
P14 Provider outcome certainty and ambiguous reconciliation Proposed Relay generic child, separate coordinated transactional/campaign sender owner Relay aisl/campaign owner ACK; P03/P04/P09 audit contract Distinguish known provider reject from unknown response for BOTH transactional/campaign sends. Unknown provider acceptance/timeout/connection loss remains ambiguous; no automatic requeue/resend. Audited evidence-based reconciliation, assume-sent/retry, no second provider call from duplicate queue delivery. Provider accepts then response lost; duplicate worker/queue after ambiguity, stale postclaim result, no provider call on auto recovery; known reject retry policy and actor-attributed manual reconciliation. Cross-card preservation contract
P15 Calendar lifecycle MIME and iTIP Proposed generic Relay MIME child; minimal AISL event lifecycle adapter P07 Relay transport/aisl owner and AISL events ACK; P14 outcomes; P07 trigger contract Exact multipart/alternative[text/plain,text/html,text/calendar-last], no Content-Disposition. METHOD REQUEST/CANCEL; stable UID/increasing SEQUENCE; future-event updates/cancellation, attendee and host-access lifecycle-scoped dedupe. Existing target multipart/mixed attachment capability is partial. Retain donor raw path until accepted replacement. Inspect raw MIME topology/order/disposition; REQUEST/update/CANCEL with UID/SEQUENCE; attendee/host replay and future-event fanout; no duplicate send or degradation. No normal-attachment substitution. A01

Current anchored inventory enumeration has 64 unique rows (59 non-A and 5 scoped absence), with one primary assignment each and zero gaps/duplicates. This is an input receipt, not a fixed future completeness rule. Enumerate again against actual accepted frozen inputs; template keys and purposes are separate dynamic catalogs. M01–M14 findings map to these cards; U01–U06 remain owner/re-audit unknowns. Source/test references are not executed proof.

Acceptance criteria

  • AC1 Coverage: enumerate donor IDs and dynamic template keys/purposes from frozen inputs. Every required ID has an accepted replacement, primary owner, source hash, executed contract evidence and any required owner receipt. Mapping to an issue, a static test reference, or package-only synthetic success does not close the row. No fixed 57-template or one-template-per-purpose assumption.
  • AC2 Bundle: preserve subject/body/footer as one overriding record, override-only keys, classification/sender metadata, required contexts and preview variants. No stripping/truncation. Nonempty footer fails closed until #29 is accepted. Whole-bundle validation precedes writes; invalid late item creates no rows/versions/queue/network side effects. Atomic apply, deterministic manifest/checksums and replay do not mutate published versions or duplicate publication. AISL export and Relay consumer have one schema owner and separate repositories.
  • AC3 Rendering: compare AISL and Relay subject, plain text, HTML/chrome/footer/actions across the dynamic catalog, named/nameless contexts, representative recipient timezones/DST, file/override paths, verified/unverified and verify-footer opt-outs, promotional unsubscribe and transactional absence. Preserve authored formatting/links and plain-text action order. Use content-safe synthetic rendered evidence; list each permitted normalization and why it cannot hide a visual or semantic change. Relay default shell/Markdown source-as-text is not presumed equivalent. A generic first-class profile may supply parity; no donor renderer clone or unsolicited redesign.
  • AC4 Delivery: transactional/promotional are semantic kinds; welcome is a transactional sender override, not a team kind. Honor runtime sender precedence, valid Reply-To/omit-invalid behavior, CC/BCC/configuration set, unsubscribe headers including configured mailto, recipient suppression and reason codes. Preserve exact calendar iTIP MIME: multipart/alternative with text/plain, text/html, text/calendar last; no Content-Disposition; METHOD REQUEST/CANCEL, stable UID and increasing SEQUENCE, future-event lifecycle rules and attendee/host-access scoped dedupe keys. Target multipart/mixed attachment primitives are partial support, not parity. Preserve non-user operator notices, privacy redaction, kill-switch/readiness checks, rate isolation and explicit transport ambiguity. BOTH transactional and campaign unknown provider outcomes must enter an auditable ambiguous state, never automatically requeue/resend; a lost provider response after acceptance is not a known rejection. Operator reconciliation/assume-sent/retry needs actor attribution and evidence preventing a second provider call.
  • AC5 Campaigns: preserve tier/tag include/exclude, Slack and verification tri-state, event scope, recount, immutable audience snapshot, per-recipient locking/claims, send-time consent reasons, attempts/recovery, retry and attributed assume-sent. API authoring cannot become a send endpoint. Preserve recording-available prefill and test-send behavior. Campaign From is promotional; donor campaign Reply-To is omitted (welcome-only Reply-To remains separate). HTML/plain-text unsubscribe URL and header HTTPS URL use the same recipient token, with configured mailto and exact List-Unsubscribe-Post: List-Unsubscribe=One-Click. Campaign test sends use fixed no-unsubscribe-link explanatory preview content and create no donor live-history EmailLog; random live tracking/unsubscribe tokens must not replace that safe preview. Pilot100/follow-up250, monitoring-start plus24h, at least2% bounced confirmed rows and at least1 complaint gate each current wave and cumulative totals. Do not narrow to hard bounces. Pending/live claims, failed/ambiguous/expired claims, no confirmed sends, monitoring not started and campaign complete block release as donor policy requires; manual resume cannot bypass gates. Persist release time/actor, ordered membership, monitoring start, wave/completion/resume state across process restarts; derive these from existing records only with an explicit equivalence proof, otherwise use durable wave records. Exact clock/count boundary and concurrency tests are required. Re-permission preserves fixed consent copy, sole CTA, 30-day token, preview-only URL, persisted-user live-send requirement and unverified-only wave coupling; no action stops marketing while transactional mail remains available.
  • AC6 Consumer behavior: dynamic purpose→template/kind/sender mapping covers all producers and resolver contracts, not just files. Live binding/expiry checks fail closed; delivery-time token clocks and URL minting persist only scalar inputs; durable context and hash stay unchanged. Before any durable row/job, recursively reject absolute/scheme-less URLs, bearer-query and AWS-signed URL forms; only a top-level sanitized return_path is permitted. Errors expose purpose and path, never rejected values. Final rendering legitimately contains links: output validation does not replace the durable-context guard. Worker resolvers augment only an in-memory copy and reject missing/stale/expired/mismatched relationships permanently with safe reason codes. Preserve preferences newsletter mirror without altering scoped keys, double opt-in/no enumeration/throttle, verification/reminders/purge, soft-bounce event-id-idempotent accumulation and three-strike transition, bounded/redacted diagnostics, hard-bounce/complaint precedence and send-time suppression, plus callback recovery. Any v1 identity gap needs an accepted generic contract revision, not a guess.
  • AC7 Jobs/idempotency: register every email schedule and handler with equivalent cadence; preserve post-commit dispatch, durable ledger/claims, retry classes/attempt budgets and ambiguity-never-auto-retry. Define stable client/source namespaced keys for lifecycle/campaign/provider imports across old/new senders. Replays, concurrent claims and callback reorder/duplicates produce no extra sends or state regression.
  • AC8 History: #26 owns generic import; existing transfer owner remains sole old-instance importer. Preserve original IDs/times/provider IDs, rendered subject snapshots, event taxonomy/raw provenance, engagement counts/correlations, bounce diagnostics, aliases/merge/rename continuity, seven identity/conflict/reconciliation states, strongest disposition (complained > bounced > clicked > opened > delivered > sent) and chronological order. Primary/alias/send-log agreement and contradictory evidence fail closed; never silently coalesce distinct contacts. Preserve historical recipient snapshots and mixed imported/new chronology. Synthetic10,000-row double import creates zero rows on second run, no immutable mutation/send/callback side effects; rejects/counts/IDs/checksums reconcile. Then separate approved development-copy donor equivalence receipts are required. The reported old Relay55,207 event transfer and rejected HTML rows are not AISL proof.
  • AC9 Operator/recipient UX: existing AISL screens/routes/tasks remain available through thin adapters until accepted preservation; no redesign, silent screen removal or route break. Map every donor operator and staff/admin/API task to retained equivalent surfaces and permissions, search/filter/page/detail/diagnostic, editing/preview/test-send, wave/recovery, prefill and CSV workflows. Test-send retains donor audit/privacy semantics while Relay may retain its own clearly separated audit. Independently rendered evidence covers changed screens and email outputs; existing target UI tests alone cannot prove donor parity. No hidden loss of empty/error/reconciliation states.
  • AC10 Operational gates: D13/four clean weeks, #25 owner-operated sender/domain provisioning and canary, real overrides/runtime configuration reconciliation, A6.1 import/publish/render conformance, A6.2 contacts and callbacks, A6.3 rehearsal/history and A6.4 controlled cutover remain open until actual owner receipts. Agents never access production databases/credentials. Durable freeze/fence enqueue, classify/drain/transfer queued intents, revoke stale leases, reconcile ambiguous/provider-accepted outcomes and stable cross-backend idempotency prevent duplicates/gaps. Rollback pauses Relay, reconciles accepted sends and restores only unsent intents before donor resumes. Storage/SES/scheduler contraction requires a separate accepted replacement and deletion ledger.
  • AC11 Verification/process: independent Tester executes fresh commit-bound relevant unit/service/view/critical browser gates with stubbed SES/SQS and required lint; PM checks fidelity after actual terminal receipt. Report static_present, test_reference_pending, executed_receipt and owner_receipt_pending separately. No source/main CI borrowing, cloud evidence invention or weakened standards/gates. Each child has a reviewable cohesive ownership plan and size evidence.

Completion and stop conditions

#30 stays open until all required donor rows and AC1–AC11 have accepted receipts, operational dependencies are satisfied by authorized owners, and no useful AISL feature/UI/recipient/history behavior is lost. Bounded local synthetic capability acceptance may be recorded separately and never described as full adoption. Block on missing owner ACK, unsupported footer/profile/attachment/identity contract, unexplained rendering differences, failed gate, incomplete inventory or donor reconciliation; fix/groom the specific child instead of dropping scope.

Implementation remains blocked until current owner scope/path acknowledgements and child grooming/dependency gates. Source changes, verification, commits and CI observation follow the existing repository roles. Production access by agents remains prohibited; any future operational import/send/deployment/cutover/cleanup is solely an authorized owner's separate task.

Lingua principale
Python
Stelle
0
Fork
0
Merge medio
11m
PR unite (30g)
4

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

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 DataTalksClub/relay

Tutte le issue di DataTalksClub/relay

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.