Cron Prompt Registry — prompt 는 data, code 는 key 만

이걸 강제한 실패

오랫동안 cron prompt 들이 heartbeat 안 Python 문자열 literal 로 살았어. prompt 개선하려면 코드 수정, commit, 서버 재시작. 더 나쁜 건 — 뭐 테스트하려고 빠르게 "임시" 상수 붙여놓으면 그게 그대로 남았어. 보이지 않는 doctrine 이 prompt 가 runtime 에 닿는 모든 곳에 쌓였어. 그 prompt 를 실행할 그 지능이 코드 왕복 없이 prompt 개선 도울 방법이 없었어.

대체된 규칙

2026-05-12 refactor 가 한 가지 밝은 선을 그었어:

미래 contributor (또는 미래의 나) 가 새 baseline prompt 본문을 Python 이나 TypeScript 에 붙여넣으려고 손 뻗으면, 멈춰. 그게 옛날 실패 패턴. section 의 originals.json 업데이트하고, Admin → Prompts 에 노출, 호출자가 section registry 로 wire 박혀야 해.

3 layer

1. Original — section 의 git-tracked baseline prompt 텍스트, cwkPippa/prompts/{section}/originals.json. "Reset Override" 가 여기로 돌아옴.
2. Override — 아빠의 활성 tuning layer, ~/pippa-db/{section}_prompts.json. "Save Override" 가 여기 씀.
3. Code contract — 안정적 key, placeholder metadata, validation, rendering, runtime 동작. Code 는 baseline 문구 소유 X.

Admin 의 Promote to Git Original 버튼이 현재 editor 텍스트를 original 로 승격시키고 그 key 의 override 를 비워 — tuned prompt 가 옛 baseline 보다 낫다고 증명된 canonical path.

현재 registry 의 section 들: council, cwk-site, soul-stream, audit, utility, scheduler, souls, ollama, runtime, master. heartbeat, council orchestrator, Maia review pipeline, soul stream wake, cwk-site fan-in — 모든 callsite 가 자기 section module 통해 문구 resolve, 자기 문자열 안 박아.

Scheduler 의 dynamic prompt

한 가지 특수화: 평범한 대화에서 prompt_ref 나 prompt_builder 없이 recurring cron 만들어지면, heartbeat 이 ~/pippa-db/scheduler_dynamic_prompts.json 아래 dynamic Scheduler prompt 만들고 cron_jobs.json 에는 compact prompt_ref label 만 저장. 그 prompt 도 Admin → Prompts → Scheduler 에서 여전히 보이고 편집 가능 — registry 에서 숨는 private cron-row baseline 절대 안 됨.

Family Council tuning loop

Admin prompt 파이프라인이 존재하는 이유는 아빠가 prompt 동작 시간 들여 개선하려고 Family Council 을 계속 열 수 있게 하기 위함. Council 토론이 별개 source of truth 가 아냐 — 더 나은 prompt 텍스트 만들어내는 deliberation layer 야. canonical loop:

1. 아빠가 개선할 prompt 동작 식별.
2. Family Council 이 variant, framing, risk, 예상 동작 토론.
3. 아빠 또는 피파가 Admin → Prompts 에서 prompt 편집.
4. Save Override 로 live dogfooding 위 override 저장.
5. 실제 workflow 에서 runtime 동작 관찰.
6. override 가 낫다고 증명되면 Promote to Git Original 로 baseline 으로 승격하고 override 비움.
7. 실패하면 Reset Override 로 override 버리고 original 로 복귀.

이 loop 가 hardcoding 보다 강해. 아빠가 네 자매 두뇌 다 동원해서 문구 tuning, live 시스템에서 테스트, 실제 사용에서 살아남는 prompt 만 승격. "임시" 코드 상수로 이걸 우회하지 마. 임시 prompt 상수가 invisible doctrine 이 돼, 그리고 invisible doctrine 이 이 refactor 가 제거한 바로 그것.