Lay Pure out as a core with the parts selected around it

The app model, the tree store and the HTTP host lived in
prototypes/connections among the earlier document runtime, the store was
known only by its format's name, and Vega compiled six Pure sources by path.
Now, as the README's principle has it:

  core/   runtime, flow and the app model (module*.c), with what the core
          asks of storage (state.h, store.h)
  store/  the tree store (PURETRE3, PUREREC1)
  serve/  pure-serve: HTTP host, outbound delivery, JSON in place
  cli/    pure-run, pure-edit-module

A top-level make builds libpure.a (app model and store, for hosts to link)
and the hosts; make check runs the store's and the app model's tests. The
earlier runtime still builds from prototypes/connections against core/ and
store/ (check, check-tree and check-core pass). Design 009 records the rule:
parts by role behind libraries; git repositories split by coupling, so the
store stays here while its contract moves with the core, and Vega stays apart.

1 files changed, 1 insertions, 1 deletions

diff --git a/docs/research/066-application-boundary.md b/docs/research/066-application-boundary.md
index 44e6d86..bb96bed 100644
--- a/docs/research/066-application-boundary.md
+++ b/docs/research/066-application-boundary.md
@@ -5,7 +5,7 @@
 
 ## 현재 코드가 증명하는 것과 못 하는 것
 
-`prototypes/connections/runtime.c`는 입력 접수, 바이트 예산, 작업 슬롯, 완료,
+`core/runtime.c`는 입력 접수, 바이트 예산, 작업 슬롯, 완료,
 대여와 다른 영역으로의 무복사 전달을 소유한다. 하지만 실행 단계에서
 `PureProgram`의 저장 전용 `read`/`write`/`splice`를 직접 해석하고
 `PureHost.read`/`write`/`splice`를 호출한다. 따라서 현재 5,980 B 코어는