wlsdks / atlas-grow

/atlas-grow — 다음에 채울 곳

규율 하나 — 제안 단계는 절대 쓰지 않는다

사람이 고른 것만 볼트에 들어간다. 지어낸 노드는 이 도구가 낼 수 있는 최악의
결과다 — 틀린 지도는 없는 지도보다 나쁘다. 없으면 사람이 직접 찾아보지만,
틀린 것이 있으면 그걸 믿고 결정한다.

1. 지금 어디까지 왔나

• query_ontology({ operation: 'agent_brief' }) — 이 볼트의 시작점과 다음 행동
• query_ontology({ operation: 'growth_plan' }) — 무엇이 비어 있나

1. 후보를 근거로 거른다

받은 후보를 그대로 옮기지 않는다. 하나씩 셋을 통과해야 남는다.

• 실재하는가 — 이름만 그럴듯한 게 아니라 코드나 문서에 근거가 있나.
  find_evidence({ title }) 로 확인한다. 코드 폴더가 묶여 있으면
  analyze_repo_structure · infer_imports 가 근거를 준다.

• 이미 있는가 — query_concepts({ filter }) 로 비슷한 이름을 먼저 찾는다.
  있으면 새로 만들지 말고 그것을 patch_concept(expected_mtime 함께)로 채운다.

• 뜻이 있는가 — 자리 말고 다른 이유가 있어야 element 다. 파일 하나마다
  노드 하나를 만들면 그건 지도가 아니라 파일 목록이다.

1. 사람에게 보여 준다

한 번에 다섯 개까지. 줄마다 셋을 적는다 — ① 무엇을 ② 어디에 붙이고
③ 왜 그렇게 보는지(근거). 「전부 만들까요?」라고 묻지 않는다. 번호를 붙여서
골라서 답할 수 있게 한다.

1. 승인된 것만 쓴다 — 그리고 확인한다

• 노드: add_concepts (많으면 50개씩 나눠서)
• 노드가 전부 성공한 다음에 관계: add_relations
• validate_vault({}) → query_ontology({ operation: 'health' })

새 도메인은 저절로 프로젝트에 안 붙는다.
add_relation('<project>', 'domains/<새 도메인>', 'domains') 를 빠뜨리면
만들어 놓고 지도에 안 보인다. 4번의 health 가 그것을 잡는다.

이 스킬이 실패하는 방식

• 근거 없이 그럴듯한 이름을 만들어 낸다
• 이미 있는 것을 못 찾아 비슷한 노드를 하나 더 만든다
• 묻지 않고 쓴다
• 노드만 만들고 관계를 안 걸어서, 만든 것이 어디에도 안 보인다
• 쓰고 나서 확인을 안 해, 깨진 것을 사람이 나중에 발견한다