266 lines
19 KiB
Markdown
266 lines
19 KiB
Markdown
---
|
|
title: daily-tasks / Hub
|
|
source_type: meta
|
|
status: stable
|
|
tags: [meta, daily-task, hub]
|
|
last_reviewed: 2026-05-28
|
|
---
|
|
|
|
# daily-tasks / Hub
|
|
|
|
> Layer: `raw/daily-tasks/` — **매일 아침 학습용 실습 과제** 의 카테고리 진입점. 사수가 신입에게 주는 형식의 자율 학습 과제를 두 트랙으로 분리 누적.
|
|
|
|
## 0. 한 줄 요약
|
|
|
|
| 항목 | 값 |
|
|
|---|---|
|
|
| 사용 cadence | 매일 아침 |
|
|
| 트랙 | `develop/` + `infra/` 두 가지 동시 진행 (각 ~2시간) |
|
|
| 1과제 분량 | `duration_estimate: 120` 분 default (Pomodoro 4-5개) — *완료 신호* 까지의 자기 추정치 |
|
|
| Template | `templates/daily-task-develop-template.md` / `templates/daily-task-infra-template.md` |
|
|
| 산출물 | branch (`daily-task/<track>/<slug>`), commit/PR, manifest, dashboard/alert, 회고 |
|
|
| Promotion 경로 | `verified` 항목만 `/ingest` 로 `wiki/concepts/` 또는 `wiki/projects/` (CLAUDE.md §15) |
|
|
|
|
## 1. 폴더 구조
|
|
|
|
```text
|
|
raw/daily-tasks/
|
|
├── README.md ← 이 파일 (hub)
|
|
├── develop/
|
|
│ └── YYYY-MM-DD-<implementation-slug>.md ← 매일 1개
|
|
└── infra/
|
|
└── YYYY-MM-DD-<implementation-slug>.md ← 매일 1개
|
|
```
|
|
|
|
## 2. 명명 규칙
|
|
|
|
- 파일명: `YYYY-MM-DD-<implementation-slug>.md`
|
|
- `YYYY-MM-DD` = `target_date` (수행 예정일). 미래 과제를 미리 작성해도 무방.
|
|
- `<implementation-slug>` = **무엇을 배우고 구현하는지** 를 4~7 단어 영문 kebab-case 로. 슬러그만 보고도 과제 내용 파악 가능해야 함.
|
|
- 좋은 예:
|
|
- `develop/2026-05-29-archunit-controller-domain-return-rule.md`
|
|
- `develop/2026-05-30-jackson-fail-on-unknown-properties-policy.md`
|
|
- `infra/2026-05-29-actuator-readiness-probe-db-disconnect.md`
|
|
- `infra/2026-05-30-prometheus-pod-restart-alert-rule.md`
|
|
- 나쁜 예 (금지):
|
|
- ❌ `develop/task-1.md` (의미 zero)
|
|
- ❌ `infra/day-3-monitoring.md` (numbered hierarchy + 의미 부족)
|
|
- ❌ `develop/오늘과제.md` (한글 파일명)
|
|
- 자세한 규칙: [[rules/naming-conventions]] (§2.2.1 daily-task 명명)
|
|
|
|
## 3. 두 트랙의 차이
|
|
|
|
| 항목 | develop | infra |
|
|
|---|---|---|
|
|
| 주 산출물 | 코드 commit / PR / 테스트 / ArchUnit rule | manifest / config / probe / alert rule / dashboard |
|
|
| 검증 채널 | unit test, contract test, build pipeline | kubectl + promql + log query + smoke test (≥2 채널 교차) |
|
|
| §5 흐름 | 코드 작성 → 테스트 작성 → 빌드 → PR | manifest 작성 → apply → 관측 → 롤백 drill |
|
|
| 시간 분포 | CPU bound (Pomodoro 직접) | apply / 수렴 *대기* 시간 포함 |
|
|
| 회복력 anchor (§11) | 없음 | **있음** — fail-fast vs degrade, 롤백 트리거 |
|
|
| Template | [[templates/daily-task-develop-template]] | [[templates/daily-task-infra-template]] |
|
|
|
|
## 4. 트랙별 6-month 커리큘럼
|
|
|
|
> 매일 1과제 × 2트랙을 6개월 (약 130 영업일) 진행했을 때 도달 목표를 *시니어 초반급 문제해결력* 으로 설정. 단순 지식 누적이 아닌 *trade-off articulation / system thinking / failure-mode awareness / root-cause tracing* 4역량의 동시 향상.
|
|
>
|
|
> **목표 정의 근거**: `[[raw/company-tech-blogs/senior-engineer-competency-mubin-shaikh]]#SR-MUBIN-C1` (system thinking — latency/throughput/failure-mode 까지), `#SR-MUBIN-C3` (trade-off 명시 — "best practice" 인용은 senior 미달), `#SR-MUBIN-C4` (증상 아닌 근본 원인 + 재발 방지까지), `#SR-MUBIN-C5` (커리어 초반=무엇을 만드는가, 후반=어떤 결정을 주도하는가).
|
|
>
|
|
> **격상 위험 주의** (raw 의 ELEV-1, ELEV-2): 본 anchor 는 *personal-blog 단독* 근거. 커리큘럼 본문에서 인용할 때는 "Mubin Shaikh 관점에서" 또는 "참고 기준으로" 한정. *공식 industry standard* 처럼 표현 금지.
|
|
|
|
### 4.0 4역량 anchor — *시니어 초반급* 의 조작적 정의
|
|
|
|
| 역량 | 의미 | 측정 신호 (도달 시) | 인용 |
|
|
|---|---|---|---|
|
|
| **System thinking** | 코드 한 함수가 아닌 시스템 전체 (request 진입~응답 반환 + 의존성 + 실패 전파) 로 사고 | 새 feature 를 *requirements → deployment → 운영* 까지 혼자 설계 가능 | `#SR-MUBIN-C1` |
|
|
| **Trade-off articulation** | 모든 결정에 "왜 이걸 골랐고 왜 다른 걸 안 골랐는가" 를 *최소 2-3개* 댈 수 있음. "best practice 이니까" 거부 | 자기 PR 의 design choice 를 1분 안에 3개 trade-off 와 함께 설명 | `#SR-MUBIN-C3` |
|
|
| **Failure-mode awareness** | 정상 path 가 아니라 *어떻게 깨지는가* 부터 설계. 새 기능 도입 시 새 실패 모드를 함께 명시 | 새 코드 / manifest 의 §11 운영 회복력 anchor 가 빈칸이 아님 | `#SR-MUBIN-C1`, `#SR-MUBIN-C4` |
|
|
| **Root-cause tracing** | production issue 를 증상 (retry 실패) 이 아닌 근본 원인 (idempotency 누락) 까지 추적. 재발 방지 (alert / contract test) 까지 책임 | issue 1건당 fix + alert + contract test 의 3-pack 결과 | `#SR-MUBIN-C4` |
|
|
|
|
매 phase 끝에 위 4역량을 0~5 self-rate. 6개월 끝에서 모두 ≥ 3 이 목표 (`참고 기준`, Mubin Shaikh 관점).
|
|
|
|
### 4.1 develop 트랙 — 6 phase (각 4주)
|
|
|
|
| Phase | 핵심 anchor | 시니어 사고 강제 (trade-off) | 산출물 |
|
|
|---|---|---|---|
|
|
| **D-P1** Boundary Contract Enforcement | ArchUnit, Spring MVC exception, Bean Validation 4-layer, mapper boundary | 정적 분석 vs runtime 검증 trade-off / false-positive vs leak coverage | 5-8 ArchUnit rule, mapping exception classifier, contract test 묶음 |
|
|
| **D-P2** Mapper & Serialization Safety | record + canonical constructor, MapStruct optional, Jackson polymorphic 보안 (CVE-2019-14379 패턴), PATCH semantics (RFC 7396 미채택) | 수기 mapper vs generated trade-off / `enableDefaultTyping` 보안 vs 편의 / null=deletion vs absent 의미 | mapper 패턴 카탈로그 + polymorphic deserialization 보안 test + PATCH endpoint 3-상태 contract |
|
|
| **D-P3** Data & Transaction Contract | JPA, `TransactionPort` 추상화, optimistic / pessimistic lock, idempotency key, repository capability | tx 경계 위치 (controller/service/UC) trade-off / lock 종류 선택 / idempotency table vs request-key cache | TransactionPort 구현 + idempotency 처리 + capability 테스트 |
|
|
| **D-P4** Domain Event & Async Boundary | outbox pattern, transactional event publish, async executor, virtual thread (Loom) 호환성 | 동기 vs 비동기 trade-off / outbox 폴링 주기 vs latency / virtual thread + ThreadLocal MDC | outbox publisher + async boundary test + virtual thread compatibility test |
|
|
| **D-P5** API Surface & Schema Evolution | OpenAPI spec-first, contract test, API versioning, breaking change 분류 | spec-first vs code-first trade-off / version 전략 (header/path) / unknown field 허용 시점 | OpenAPI v1 + spec drift detection + deprecation policy |
|
|
| **D-P6** Performance & Concurrency | JMH micro-bench, async profiler, jstack 분석, concurrency primitives (ReentrantLock vs synchronized vs StampedLock) | latency vs throughput trade-off / bench reliability (warmup, GC noise) / lock 선택 | JMH report + bottleneck analysis + lock comparison |
|
|
|
|
#### D-P1 상세 — *시작 phase, 모든 후속 phase 의 baseline*
|
|
|
|
- **진입 조건**: ca-tmpl 빌드 통과, ArchUnit 의존성 추가 가능
|
|
- **학습 anchor**:
|
|
- [[raw/branch-notes/feature-boundary-validation-mapping-contract]] D1~D14
|
|
- [[raw/official-docs/spring-mvc-rest-exception-handling]]
|
|
- [[raw/official-docs/validation-jakarta-bean-validation-3.0-spec]]
|
|
- [[raw/official-docs/schema-jackson-unknown-field-handling]]
|
|
- **변수 / 상황 anchor** (매 과제 §8 회고에 답할 것):
|
|
- rule 이 잡지 *못하는* 우회 패턴 (reflection / generic Object 반환 / dynamic proxy) — 어디까지 ArchUnit 으로 가는 게 합리적인가?
|
|
- false positive 1건 vs leak 1건의 비대칭 비용
|
|
- generated code (MapStruct, Lombok) exemption 의 위치
|
|
- **시니어 초반급 도달 신호** (이 phase 끝났을 때):
|
|
- controller / service / DTO 의 boundary leak 시나리오 *5개* 를 trade-off 와 함께 설명 가능
|
|
- 새 rule 추가 시 *false positive 측정* 부터 시작하는 절차가 몸에 익음
|
|
- **예상 과제 흐름** (영업일 기준):
|
|
- W1: controller return type rule + JSON leak integration test (오늘 작성된 첫 과제로 시작)
|
|
- W2: request DTO → application 직접 전달 금지 rule + Bean Validation group sequence
|
|
- W3: Mapping exception classifier + ResponseEntityExceptionHandler 확장
|
|
- W4: Jackson deserialization 정책 강제 + integration cross-check
|
|
|
|
#### D-P2 상세
|
|
|
|
- **진입 조건**: D-P1 의 boundary contract 가 코드로 강제됨
|
|
- **학습 anchor**:
|
|
- [[raw/official-docs/schema-jackson-polymorphic-deserialization]] (CVE-2019-14379 포함)
|
|
- [[raw/official-docs/patch-json-merge-rfc7396]]
|
|
- **변수 / 상황 anchor**:
|
|
- MapStruct generated code 가 build 마다 stale 가능 → CI 검증
|
|
- sealed `Command` interface 의 Jackson 2.15+ 자동 인식 vs 명시 `@JsonTypeInfo` trade-off
|
|
- PATCH `null` 의 의미 (3-상태) 를 OpenAPI 에 어떻게 노출하는가
|
|
- **시니어 초반급 도달 신호**:
|
|
- polymorphic deserialization gadget chain 의 *공격 시나리오* 를 1개 그릴 수 있음
|
|
- PATCH 의 silent overwrite 버그 패턴을 코드 리뷰에서 즉시 잡아냄
|
|
|
|
#### D-P3 ~ D-P6 (요약, 상세는 phase 진입 시 README 갱신)
|
|
|
|
각 phase 진입 시 *그 phase 의 첫 주차에* 본 README 의 해당 sub-section 을 D-P1/D-P2 와 동일 깊이로 채운다 — *phase 진입은 README 갱신부터*. 이게 진행 추적 anchor.
|
|
|
|
### 4.2 infra 트랙 — 6 phase (각 4주)
|
|
|
|
| Phase | 핵심 anchor | 시니어 사고 강제 (trade-off) | 산출물 |
|
|
|---|---|---|---|
|
|
| **I-P1** Health & Lifecycle | actuator probe (readiness/liveness 분리), graceful shutdown, startup validation, JVM/container 자원 한계 | probe period vs detection latency / liveness 에 DB 포함의 *치명적 함정* / fail-fast vs degrade | probe contract + chaos drill + startup validation matrix |
|
|
| **I-P2** Observability Fundamentals | structured JSON log, MDC propagation, OpenTelemetry trace context (virtual thread 호환), baseline metric (RED + USE), SLO 정의 | observability cost vs coverage / sampling rate / cardinality 폭발 위험 | dashboard 묶음 + alert rule + SLO 문서 |
|
|
| **I-P3** Resilience Pattern | circuit breaker (Resilience4j), retry, rate limit, backpressure, bulkhead | retry vs idempotency / breaker threshold / queue size 의 latency 영향 | resilience 통합 + chaos test (지연/단절/burst) |
|
|
| **I-P4** Cluster Operation | k8s manifest, helm chart, rollout/rollback drill, secret 관리 (sealed secret / external secret operator) | gitops vs imperative / blue-green vs canary / secret rotation 자동화 trade-off | helm chart + rollback runbook + secret rotation drill |
|
|
| **I-P5** Capacity & Cost | HPA (CPU/memory/custom metric), resource limits, profile-driven sizing, cost reporting | over-provision (cost) vs under-provision (SLO 위험) / HPA 스파이크 vs 비용 / right-sizing 의 측정 노이즈 | sizing report + HPA policy + cost dashboard |
|
|
| **I-P6** Security & Supply Chain | RBAC, network policy, image scan (Trivy), SBOM 생성, secret rotation, supply chain attestation | security vs DX trade-off / scan blocking vs warning / sbom 검증 강도 | SBOM pipeline + image scan gate + rotation drill |
|
|
|
|
#### I-P1 상세 — *시작 phase, 모든 infra 작업의 baseline*
|
|
|
|
- **진입 조건**: 로컬 cluster (kind/k3d/minikube) + Prometheus/Grafana 가 동작
|
|
- **학습 anchor**:
|
|
- [[raw/project-notes/ca-skeleton-operational-contract]] §15 (Runtime/Lifecycle), §18 (Metrics/Alerting)
|
|
- [[raw/official-docs/runtime-health-spring-actuator-groups]]
|
|
- [[raw/official-docs/actuator-endpoint-exposure-spring-official]]
|
|
- [[raw/official-docs/actuator-management-port-spring-official]]
|
|
- **변수 / 상황 anchor** (매 과제 §8 회고에 답할 것):
|
|
- probe 가 *측정하려는 것* (트래픽 받을 준비) 과 *실제로 측정되는 것* (HTTP 200) 사이의 갭
|
|
- 측정값 간 시간차 (actuator vs kubectl vs prometheus) — scrape interval 영향
|
|
- liveness/readiness 혼동 시 발생하는 cascade failure (재기동 폭주)
|
|
- probe 자체의 timeout (actuator hang) — DB 가 죽었는데 readinessProbe 도 timeout
|
|
- **시니어 초반급 도달 신호**:
|
|
- readiness/liveness 의 운영적 차이를 *1분* 안에 설명 + 잘못 설정한 시스템의 cascade failure 시나리오 *2개* 묘사 가능
|
|
- 새 운영 변경 도입 시 *측정값 baseline → 변경 → 측정값 after → 차이 분석* 흐름이 자동
|
|
- **예상 과제 흐름**:
|
|
- W1: actuator readiness probe 분리 + DB 단절 시 측정 (오늘 작성된 첫 과제)
|
|
- W2: graceful shutdown + in-flight 요청 처리 (terminationGracePeriodSeconds 와 actuator 의 관계)
|
|
- W3: startup validation + 의도적 잘못된 env 로 fail-fast 시간 측정
|
|
- W4: JVM/container 자원 한계 시뮬레이션 + OOM 시 cleanup
|
|
|
|
#### I-P2 ~ I-P6 (요약)
|
|
|
|
D-P3~D-P6 와 동일 — phase 진입 시 본 README 의 해당 sub-section 을 채우는 것이 phase 시작.
|
|
|
|
### 4.3 변수 / 상황 anchor — 공통 메타 패턴
|
|
|
|
매 phase, 매 과제 §8 회고에 답해야 하는 메타 질문 (시니어 사고 강제):
|
|
|
|
1. **베이스라인 측정 없이 시작했는가?** — *없으면 변경 후의 "좋아졌다" 가 측정 불가*. 매 과제 §5 Step 1 은 항상 baseline.
|
|
2. **예상 결과 vs 실측의 차이는 몇 %인가?** — 일치하면 학습 0, 차이 클수록 학습 ↑. 차이가 0% 면 과제 너무 쉬움 (`difficulty` 조정 신호).
|
|
3. **이 결정의 *우회 가능 경로* 는 무엇인가?** — 정적 분석은 reflection 우회, alert 는 silent failure 우회, contract test 는 misconfig 우회. 우회 1개를 매번 명시.
|
|
4. **이 결정이 *추가하는* 실패 모드는 무엇인가?** — 새 rule 은 false positive, 새 probe 는 toggle 폭주, 새 alert 는 fatigue. 추가 실패 1개를 매번 명시.
|
|
5. ***되돌릴* 명령은 무엇인가?** — 롤백 명령을 *작성하기 전에* 코드/manifest 작성 금지. 매 infra 과제는 snapshot first.
|
|
|
|
이 5개 질문이 4역량 anchor (§4.0) 의 일상 운영판.
|
|
|
|
### 4.4 cross-track integration
|
|
|
|
매 phase 끝에 *두 트랙이 같은 도메인을 다르게 보는* cross-check 1개:
|
|
|
|
| 시점 | develop ↔ infra cross-check |
|
|
|---|---|
|
|
| P1 끝 | D-P1 의 ArchUnit rule 이 I-P1 의 probe-on-startup 검증과 일관: rule 위반 build 가 *startup validation* 단계에서도 잡히는가? |
|
|
| P2 끝 | D-P2 의 mapper masking 정책 ↔ I-P6 의 image scan 의 PII pattern. 둘이 동일 PII set 을 cover? |
|
|
| P3 끝 | D-P3 의 idempotency key ↔ I-P3 의 retry policy. retry 가 idempotency 없이 발동 시 contract test 가 잡는가? |
|
|
| P4 끝 | D-P4 의 outbox + virtual thread ↔ I-P2 의 trace propagation. virtual thread 경계에서 trace 가 끊기는가? |
|
|
| P5 끝 | D-P5 의 OpenAPI spec drift ↔ I-P4 의 helm rollout. spec drift 가 rollout 차단으로 이어지는가? |
|
|
| P6 끝 | D-P6 의 bottleneck profiling ↔ I-P5 의 HPA policy. 측정된 bottleneck 이 HPA metric 으로 연결되는가? |
|
|
|
|
### 4.5 진행 추적 / 자가평가
|
|
|
|
- 매 phase 끝 (4주차 금요일 권장): §4.0 4역량 표를 0-5 self-rate
|
|
- phase 가 4주를 넘으면 *진척이 안 나는 신호* → 학습 anchor 분할 (예: D-P2 를 mapper + Jackson 보안 2개로 쪼개기)
|
|
- 6개월 끝: 6회 self-rate 누적 → 역량별 성장 곡선 그리기
|
|
|
|
### 4.6 커리큘럼이 *틀어졌을 때*
|
|
|
|
- production / 회사 일정으로 1주 이상 멈추면: 멈춘 시점의 phase 마지막 과제 §8 회고를 다시 읽고 *그 phase 의 학습 anchor* 만 5분 재정리. *연속성* 회복 후 재개.
|
|
- 한 phase 가 *너무 쉬워서* 2주 만에 끝나면: 다음 phase 진입 *전* 에 cross-track integration 과제 1개 (§4.4) 를 끼워 깊이 보강.
|
|
- 한 phase 가 *너무 어려워서* 6주 넘어가면: 학습 anchor 를 *반으로* 자르고 새 phase 추가. 6 phase → 7 phase 로 확장 허용.
|
|
|
|
## 5. 하루 흐름 권장
|
|
|
|
```text
|
|
07:00 - 09:00 develop 과제 1개 (~2h)
|
|
09:00 - 09:15 회고 (§8) + commit/PR
|
|
09:15 - 11:15 infra 과제 1개 (~2h)
|
|
11:15 - 11:30 회고 (§8) + apply 결과 정리
|
|
```
|
|
|
|
총 4시간 (이동시간 / 휴식 미포함). 각 트랙 회고 5분은 *반드시* — 회고 없는 과제 = 학습 손실 (`raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode#DP-RGC-C4`).
|
|
|
|
## 5. 과제 시작 / 종료 절차
|
|
|
|
### 시작 시
|
|
|
|
1. 어제의 §7 "다음 과제 thread" 를 본다 → 오늘 과제 후보 선정
|
|
2. 해당 template 복사 → `raw/daily-tasks/<track>/YYYY-MM-DD-<slug>.md`
|
|
3. frontmatter 채움 (`target_date`, `difficulty`, `duration_estimate`, `parent_project`, `prerequisites`)
|
|
4. §1~§4 채움 (목표 / 스토리라인 / 환경 / 사전 지식) — *과제 시작 전* 완료
|
|
5. `status_label: in-progress` 로 변경
|
|
|
|
### 종료 시
|
|
|
|
1. §5 단계 모두 체크
|
|
2. §6 자동 검증 명령 모두 통과
|
|
3. §7 결과물 + §8 회고 채움
|
|
4. §10 Closure — `status_label: done`, 소요 시간 실측, promotable 후보
|
|
5. (infra) §11 운영 회복력 anchor 채움
|
|
6. commit / PR 푸시
|
|
|
|
## 6. Promotion / Ingest
|
|
|
|
- `done` + `actually-implemented` 또는 `locally-verified` 등급 항목만 `/ingest` 대상
|
|
- 절대 `wiki/interview/` 나 `wiki/portfolio/` 로 **직접** 이동 금지 (CLAUDE.md §15) — 반드시 `wiki/concepts/` 또는 `wiki/projects/` canonical 경유
|
|
- `documented-only` / `planned` 항목은 raw 영구 보관, wiki 추출 대상 아님
|
|
|
|
## 7. Sources / 근거 자료
|
|
|
|
본 hub 와 두 template 의 구조 근거:
|
|
|
|
| Source | 정당화 |
|
|
|---|---|
|
|
| [[raw/company-tech-blogs/skillable-hands-on-lab-structure]] | 9-section anchor (Learning Objectives / Storyline / Environment / Exercises / Assessments / Outcomes / Sources / Closure / Reflection) 의 vendor-normative 근거. **공식 best practice 격상 금지** — company-case-study 강도. |
|
|
| [[raw/company-tech-blogs/deliberate-practice-software-developers-redgreencode]] | §5 단계 분할 (slightly higher than current), §6 objective 평가, §8 reflection 의 deliberate-practice 원리. **personal-blog 강도** — Ericsson 연구 2차 인용이므로 "Ericsson 연구 기반" 표현 금지, "경험 기반 권고" 로만 인용. |
|
|
| [[raw/company-tech-blogs/senior-engineer-competency-mubin-shaikh]] | 커리큘럼 "시니어 초반급 문제해결력" 목표의 외부 anchor — mid→senior 갭(trade-off articulation, system thinking, failure-mode awareness). **personal-blog 강도** — 공식 best practice 격상 금지. |
|
|
|
|
## 8. 누적 인덱스 (수동 또는 Dataview)
|
|
|
|
> 현재는 비어 있음. 과제가 쌓이면 트랙별로 최신 N개를 본 섹션에 손으로 적거나 Obsidian Dataview 쿼리로 자동화.
|
|
|
|
### develop (최신 순)
|
|
|
|
| 날짜 | 슬러그 | Phase | difficulty | status | 검증 결과 |
|
|
|---|---|---|---|---|---|
|
|
| 2026-05-29 | [[raw/daily-tasks/develop/2026-05-29-archunit-controller-domain-return-rule\|archunit-controller-domain-return-rule]] | D-P1 W1 | intermediate | not-started | — |
|
|
|
|
### infra (최신 순)
|
|
|
|
| 날짜 | 슬러그 | Phase | difficulty | status | 측정값 / 검증 |
|
|
|---|---|---|---|---|---|
|
|
| 2026-05-29 | [[raw/daily-tasks/infra/2026-05-29-actuator-readiness-probe-db-disconnect-detection\|actuator-readiness-probe-db-disconnect-detection]] | I-P1 W1 | intermediate | not-started | — |
|