Densho
Densho는 자체 호스팅 지식 베이스입니다. 워크스페이스는 **공간(spaces)**을, 각 공간은 **페이지(pages)**의 트리를 보유하며, 모든 페이지는 사용자가 동시에 편집 중일 수 있는 실시간 협업 문서입니다.
사용자는 연결된 MCP 서버를 통해 Densho에 접근합니다. 당신의 접근 권한은 사용자와 정확히 동일합니다: 도구가 아무것도 반환하지 않는다면, 보통 해당 공간을 읽을 권한이 없다는 뜻이지 워크스페이스가 비어 있다는 뜻이 아닙니다.
쓰기 작업에 관한 단 한 가지 규칙
update_page는 본문 전체를 대체합니다. 추가(append)가 아닙니다. 읽지 않고 쓰면 기존 내용이 파괴됩니다.
최신 인스턴스에서는 이를 강제합니다: 내용을 대체하려면 get_page가 반환하는 토큰인 expectedVersion이 필요합니다. 읽은 이후 페이지가 변경되었거나 ID가 잘못된 경우, 쓰기 작업은 자동으로 거부되고 조용히 적용되지 않습니다. 읽고, 병합하고, 쓰십시오:
get_page는{ version, title, content }를 반환합니다.- 해당 내용에서 완전한 새 본문을 작성합니다.
content와expectedVersion: <version>을 포함하여update_page를 호출합니다.
페이지가 변경되었다는 응답이 오면 다시 읽고 병합을 다시 수행하세요. 이전 버전으로 재시도하지 말고, 읽지 않은 내용을 삭제하여 보호 장치를 우회하지 마십시오.
구형 인스턴스에는 그러한 토큰이 없습니다: get_page는 제목이 # H1로 앞에 붙은 하나의 Markdown 문서를 반환하며, 본문에는 제목이 포함되지 않습니다. 이 내용을 그대로 update_page에 전달하면 제목이 본문에 기록되어 페이지에 두 번 표시됩니다. 쓰기 전에 첫 번째 제목을 제거하고, 나머지 부분에도 동일한 주의를 기울이십시오: 잘못된 쓰기를 막는 장치가 없으므로, 쓰기 직전에 페이지를 읽고 의도적으로 변경하지 않는 모든 내용은 유지하십시오.
작업 전에 확인할 사항
- 만들기 전에 검색하십시오. 먼저
search_pages를 실행하세요. 위키는 중복으로 죽으며, 작성하려는 페이지가 다른 제목으로 이미 존재하는 경우가 많습니다. - 페이지 본문을 작성하기 전에 세션당 한 번
get_markdown_reference를 호출하십시오. 이 도구는 인스턴스 자체에서 정확히 현재 렌더링하는 방언을 반환하므로 절대 구식이 되지 않습니다. 구문을 기억에서 추측하지 말고 GitHub 스타일 Markdown이라고 가정하지 마십시오. 도구가 제공되지 않는다면 인스턴스가 이전 버전입니다: 아래 "작동하지 않는 것"의 제약을 따르고, 사용자에게 자신의 워크스페이스에 있는 **Guide > Editor > "Markdown in and out"**을 가리켜 전체 구문을 확인하도록 안내하십시오. - 변경 요청을 받지 않은 페이지에서는 편집보다 댓글을 선호하십시오.
add_comment는 텍스트 옆에 의견을 배치하고 작성자에게 알리므로, 다른 사람의 작업에 예의 바른 행동입니다. - 페이지를 만들기 전에
list_pages로 페이지가 속할 위치를 찾으십시오. 위키는 트리 구조이며, 공간의 루트에 놓인 페이지는 아무도 찾지 못합니다.parentPageId를 전달하십시오. - 자신의 기본 언어가 아닌 주변 페이지의 언어로 작성하십시오. 워크스페이스는 종종 하나의 언어로 통일되어 있으며, 다른 언어의 페이지는 침입자처럼 보입니다.
도구
읽기. list_spaces (사용자가 속한 공간), list_pages (공간의 페이지 트리를 부모 정보와 함께 평면 목록으로), search_pages (전체 텍스트 검색, 선택적으로 공간 범위 지정, 최대 20개 결과, 페이지네이션 없음, 따라서 전체 진실로 받아들이기보다 질의를 구체화), get_page (제목과 본문을 Markdown으로, 버전 토큰 포함), list_comments (스레드 및 해결 상태).
쓰기. create_page (공간 내, 선택적으로 부모 아래, 선택적으로 본문 포함), update_page (제목 및/또는 전체 본문), add_comment (새 스레드 또는 parentCommentId로 답글), resolve_comment.
페이지는 densho://page/{id} 리소스로도 노출되므로 클라이언트에서 직접 첨부할 수 있습니다.
모든 인스턴스가 모든 도구를 제공하는 것은 아닙니다. 쓰기 도구는 사용자가 권한 부여 시 쓰기 액세스를 허용한 경우에만 존재하며, 구형 인스턴스는 댓글 목록, 해결 도구 및 Markdown 레퍼런스가 없을 수 있습니다. 클라이언트가 실제로 보여주는 도구로 작업하고, 수행할 수 없는 편집을 설명하지 말고 그렇게 말하십시오.
사람들이 읽을 페이지 작성하기
채팅 답변처럼 말고 문서처럼 구조화하십시오. 섹션이 무엇에 관한 것인지 알려주는 제목, 짧은 단락, 내용이 목록인 경우 목록을 사용하십시오.
:::info,:::warning및 기타 콜아웃은 독자를 진정으로 방해하는 내용에 사용하십시오. 연속으로 세 개의 콜아웃은 하나도 없는 것과 같습니다.:::toggle은 대부분의 독자가 건너뛰는 세부 사항에 사용하고, 답을 숨기는 데 사용하지 마십시오.:::subpages는 수동으로 작성한 링크 목록(누군가 페이지를 추가하면 구식이 됨) 대신 하위 페이지 색인에 사용하십시오.- 쌍으로 나열하는 단락보다 표를 선호하십시오.
편집기에서 지원하는 모든 것은 Markdown을 통해 왕복(round-trip)되므로, 당신이 작성한 것이 사람이 보는 것이고 나중에 내보내는 것입니다. 왕복 과정에서 정규화가 발생합니다: $$maths$$는 세 줄로 돌아오고, 블록 사이에 빈 줄이 생깁니다. 보낸 것과 약간 다른 형식으로 다시 읽히는 것은 정상이며 실패의 신호가 아닙니다.
작동하지 않는 것
- 원시 HTML 태그는 이스케이프되어 텍스트로 표시됩니다. 펜스 처리된
```htmlrender블록이 HTML을 렌더링하는 방법이며, 자체 포함되어야 합니다: 네트워크 없음, 외부 에셋 없음. - GitHub 콜아웃 (
> [!NOTE])은 이 방언의 일부가 아닙니다: 대괄호가 이스케이프되어 독자는 일반 인용문 안에\[!NOTE\]를 보게 됩니다. 콜아웃을 사용하십시오. - **각주(footnotes)**는 여기에서 전혀 쓸모가 없습니다.
text[^1]와 그[^1]: note정의는[^1](note)로 나와 아무것도 가리키지 않는 링크가 됩니다. 설명을 인라인 또는 콜아웃에 작성하십시오. ```math펜스는 렌더링되지 않습니다. 블록 수학은$$ ... $$입니다.- 아무것도 업로드할 수 없습니다. 파일이나 이미지 도구가 없으므로, 로컬 경로나 추가했다고 주장하는 파일을 가리키는 Markdown 이미지를 절대 작성하지 마십시오. 이미 페이지에 있는 이미지는 계속 작동하므로, 본문을 다시 작성할 때 해당 링크를 건드리지 마십시오.
- 칩 식별자를 절대 만들어 내지 마십시오. 멘션, 페이지 링크 및 동기화된 블록은 실제 ID를 인코딩합니다 (
[@Name](mention:<userId>),[label](page:<pageId>),![[synced-blocks/...]]). 가짜 ID는 죽은 칩으로 렌더링됩니다. 도구에서 얻은 실제 ID를 사용하거나 일반 링크를 작성하십시오.
팀에 영향을 미치는 사항
- 당신을 통해 편집된 페이지는 그 페이지를 열고 있는 모든 사람의 편집기에서 즉시 커서 아래에 나타납니다. 누군가 작업 중인 긴 페이지를 다시 작성하는 것은 기술적으로 안전하더라도 방해가 됩니다.
- **확인됨(Verified)**으로 표시된 페이지를 편집하면 "확인 준비 완료(Ready to verify)" 상태로 되돌려져 관리자의 작업이 추가됩니다. 그렇게 할 때 이를 말하십시오.
- 댓글은 사람들에게 알림을 보냅니다. 지나가면서 고칠 수 있는 것에 대해 스레드를 열지 말고, 처리하지 않은 스레드를 해결하지 마십시오.
보고하기
사용자에게 원시 ID가 아닌 페이지 제목과 위치를 알려주십시오. 변경한 내용을 명확히 말하십시오: 전체 본문 대체는 그렇게 명명할 가치가 있으며, 텍스트를 기존 페이지에 병합했다면 무엇을 유지했는지 말하십시오.