AI-Scarlett/build-dsh-plugin

DSH 플러그인 빌드

이 워크플로우를 사용하여 DSH 플러그인 아이디어를 Harness 자체를 수정하거나 섀도잉하지 않고 표준 번들로 전환합니다.

사용자 브리프 정규화

새로운 플러그인 요청마다 intake.md를 읽습니다. 일반 언어, 최소한의 중국어 브리프, 또는 plugin-brief.template.json의 구조화된 JSON 템플릿을 허용합니다.

소스 생성 전에 다음 세 가지 의미론적 사실만 요구합니다:

1. 현재 사용자 문제;
2. 예상 사용자 결과;
3. 최소 하나의 관찰 가능한 승인 기준.

이름, 패키지 ID, 아키텍처 후보, 위험 등급, 프로젝트 구조, 테스트 및 안전 기본값을 유추합니다. 사용자가 선호도가 없는 한 Host API, Cordis 항목, 스키마, 빌드 도구 또는 테스트 전략을 설계하도록 요청하지 마십시오.

선택적 필드가 없을 경우, 소스 생성 전용, 표준 DSH 번들, 읽기 전용 동작, 실제 Profile 변이 없음, 재시작 없음, 외부 네트워크/프로세스/계정/장치 없음, 자격 증명 없음, 로컬 전용 노출, 출판 없음, E3 폐기 가능 승인을 기본값으로 설정합니다. 마켓플레이스 호환 패키지 구조로 재사용 가능한 DSH 번들을 기본적으로 빌드하지만, DSH STORE에 제출하거나 변경할 권한을 유추하지 않습니다. 모든 기본값을 가정으로 명시합니다. 출판 없음은 권한 기본값일 뿐 영구적인 금지가 아닙니다: 명시적으로 승인되고, 적절히 라이선스가 부여되며, 내부적으로 일관된 고정 릴리스는 웹사이트에서 배포하거나 마켓플레이스에 제안할 수 있습니다.

제품 결과 또는 위험 경계를 실질적으로 변경하는 질문만 합니다. 문제, 결과 또는 승인 기준이 없으면 생성이 차단됩니다. 대상 Profile, 변이 범위, 자격 증명 소유자, LAN/인터넷 보안 또는 실제 장치/계정이 없으면 해당 실제 작업만 차단됩니다. 인터페이스가 추상적으로 유지될 수 있는 경우 안전한 소스 스캐폴드를 차단하지 않습니다.

JSON 브리프가 제공되면 결정적 정규화기를 실행합니다:

node scripts/normalize-brief.mjs /absolute/path/to/plugin-brief.json
node scripts/normalize-brief.mjs /absolute/path/to/plugin-brief.json --json

정규화된 상태가 READY 또는 READY_WITH_ASSUMPTIONS이고 요청된 모드가 build-source인 경우, 또 다른 광범위한 설명 라운드 없이 단계 0–6을 진행합니다. 별도로 승인되고 완전히 지정되지 않는 한 릴리스, 실제 Profile 변이, 재시작, 자격 증명, 장치 또는 공개 노출 전에 중지합니다.

계약 수립

읽기 전용으로 시작합니다. 리포지토리 지침, 대상 DSH 버전, 공식 플러그인 문서, 관련이 있는 경우에만 활성 Profile, 그리고 하나의 현재 표준 플러그인 예제를 검사합니다. 이전 프로젝트의 API 또는 패키지 계약을 가정하지 마십니다.

항상 다음 규칙을 적용합니다:

• DSH 번들을 빌드합니다. 데스크톱 앱이나 DSH 포크를 빌드하지 않습니다.
• DSH 소스 트리 또는 @deepseek-ai/* 패키지를 절대 수정하지 않습니다.
• 공식 플러그인 인벤토리를 비활성화, 대체 또는 섀도잉하지 않습니다.
• Loader/Fiber 변이 API를 절대 호출하지 않습니다. 공개 Host 서비스와 번들 구성을 사용합니다.
• 패키지 변경에는 공식 DSH CLI를 사용합니다. 고정 인수 배열을 전달합니다. 셸 명령 문자열을 절대 빌드하지 않습니다.
• 테스트는 폐기 가능한 홈/프로필에서 유지합니다. 실제 ~/.dsh에 대해 테스트를 작성하지 않습니다.
• 자격 증명, 전체 사용자 파일, 주입된 시스템/플러그인 컨텍스트, 모델 추론 또는 개인 경로를 로그나 클라이언트를 통해 노출하지 않습니다.
• 계획, 코드 완성, 패키지 릴리스, 프로필 설치, 런타임 승인 및 외부/장치 승인을 별도 상태로 유지합니다.
• 플러그인 준비 상태, 카탈로그 후보 준비 상태, Registry PR/CI, 병합된 카탈로그, 공개 마켓플레이스 가시성 및 프로필 설치를 별도 상태로 유지합니다.
• 표준 Tool 출력, 모델 대상 렌더링, 공급자 중립 카드 의도 및 선택적 사용자 정의 클라이언트 렌더링을 별도 계약으로 유지합니다.

구현 또는 설치 전에 boundaries.md를 읽습니다. 해당 파일의 하드 블로커는 모든 점수를 무효화합니다. 모델 Tool, presentCall, presentResult, presentationMeta 또는 사용자 정의 Tool 카드를 구현하기 전에 card-contract.md를 읽습니다.

모든 중요한 결정 설명

결정 논리 없이 규칙 목록을 내보내지 마십시오. 각 아키텍처, 권한, 변이, 릴리스 또는 승인 결정에 대해 다음을 기록합니다:

1. 목적: 결정이 제어하는 실패 또는 결과.
2. 근거: DSH 메커니즘 또는 현재 위협 모델이 이를 요구하는 이유.
3. 이점: 더 안전하거나, 더 단순하거나, 더 호환되거나, 더 쉽게 검증할 수 있는 것.
4. 비용: 구현 부담, UX 마찰, 성능 비용, 기능 손실 또는 운영 지연.
5. 적용 가능성: 결정이 적절한 조건.
6. 대안: 실행 가능한 옵션, 거부된 이유 및 재고 시기.
7. 절차: 구체적인 단계, 소유자, 입력, 출력 및 롤백 동작.
8. 증거 게이트: 진행에 필요한 관찰 가능한 증거와 작업을 중단하는 조건.

플러그인을 계획, 검토 또는 설명할 때 decision-guide.md를 읽습니다. 선호하는 패턴을 분석 없이 복사하지 말고 해당 결정 카드를 사용합니다.

워크플로우 실행

전체 단계 게이트 프로세스 및 필수 아티팩트는 workflow.md를 따릅니다. 유사한 플러그인이 이전에 통과했다는 이유만으로 단계를 건너뛰지 마십시오. DSH 버전, 프로필 구성, 종속성 및 외부 서비스가 달라질 수 있습니다.

1. 호스트 적합성 증명

대상 호스트, 확장 인터페이스, 요청된 사용자 결과, 상태 변이, 외부 종속성 및 승인 표면을 식별합니다.

프로젝트가 Obsidian, VS Code, 브라우저 확장, MCP 전용 또는 입증된 DSH 번들 계약이 없는 다른 런타임을 대상으로 하는 경우 호스트 불일치를 보고하고 중지합니다. 호환 가능한 호스트 또는 의도적으로 범위가 지정된 어댑터를 제공합니다. 인접 프로젝트로 전환하지 마십니다.

호스트 계약 기록과 아키텍처 비교를 생성합니다. 게이트: compatible, adapter-required 또는 incompatible. 암시적 산문으로 남기지 마십니다.

2. 위험 분류

scorecard.md에서 하나의 클래스를 할당합니다:

• R0: 읽기 전용 메타데이터/UI.
• R1: Host 도구/서비스 또는 사용자 소유 플러그인 상태, Profile 수명 주기 쓰기 없음.
• R2: 외부 프로세스, 네트워크, 자격 증명 또는 장치 브리지.
• R3: Profile 수명 주기, 재시작, 원격 제어 또는 광범위한 관리.

불확실한 경우 더 높은 클래스를 사용합니다. 코딩 전에 비목표 및 금지된 표면을 기록합니다.

자산, 행위자, 신뢰 경계, 쓰기 표면, 실패 영향, 최소 증거 수준 및 클래스 선택 이유를 명명하는 위험 레지스터를 생성합니다.

3. 표준 패턴 선택

• Host 전용 번들: 공개 Cordis 서비스/도구를 노출하고 하나 이상의 고유한 패치 행을 제공합니다.
• Host + 클라이언트: 브라우저 코드를 분리하고 window.__ModuleLoader__.load() 및 슬롯에 등록합니다. 브라우저 코드는 Host/Node 모듈을 가져오지 않아야 합니다.
• 선택적 웹 라우트: ctx.inject(['webServer'], ...)로 등록을 지연합니다. 헤드리스/웹 없는 프로필도 여전히 부팅되어야 합니다.
• 스킬 어댑터: 격리된 스킬 파일을 마운트합니다. 외부 런타임, 확장 또는 자격 증명을 자동으로 설치하지 않습니다.
• ApiProxy 브리지: 허용 목록, 편집, 인증, 제한된 구문 분석 및 실패 시 닫힘 전송 보안으로 좁은 공개 원격 표면을 조정합니다.
• 수명 주기 관리자: 모든 프로필 변경을 R3 트랜잭션으로 처리하고 아래 변이 프로토콜을 사용합니다.
• Tool 카드 계약: 공급자 중립 presentCall/presentResult 렌더 의도를 선호합니다. 검사된 내장 어휘가 결과를 표현할 수 없는 경우에만 플러그인 소유 Tool에 대해 사용자 정의 클라이언트 슬롯 카드를 사용합니다.

dsh.bundle.patch, 패키지 확인 가능한 cordis.patch.yml, 고유 항목 ID, 명시적 파일, 버전, 라이선스 및 빌드 계약이 있는 번들 매니페스트를 생성합니다. 이후 패치 레이어는 행의 완전한 config를 대체합니다. 딥 병합하지 않습니다.

선택이 권한, 프로세스 경계, 설치 동작 또는 사용자 경험에 영향을 미치는 경우 두 가지 이상의 그럴듯한 패턴을 비교합니다. 이점과 비용을 기록합니다. 이전 프로젝트에서 사용했다는 이유만으로 아키텍처를 선택하지 마십시오.

4. 최소 권한 구현

검사된 DSH 버전에서 이미 제공하는 공개 서비스를 사용합니다. 필요한 인터페이스가 없으면 중지하고 핵심 패치 대신 어댑터 또는 업스트림 변경을 제안합니다.

읽기 전용 검색 및 드라이런/미리 보기 API를 선호합니다. 쓰기 기능은 별도로 활성화합니다. 비즈니스 로직 전에 스키마와 크기 제한을 검증합니다. 잘못된 프로필, 모호한 경로, 알 수 없는 공식 구성 요소, 오래된 상태, 재생, 동시 변경 및 누락된 증거를 거부합니다.

모든 모델 Tool에 대해 표준 출력, 모델 대상 렌더러, 대기 중인 카드, 완료된 카드, 내구성 있는 프레젠테이션 메타데이터, 범위/편집, 일반 폴백 및 라이브/재생 증거를 기록합니다. 프레젠터는 결정적이어야 하며 I/O, 시계/임의 액세스, 세션 읽기 또는 추가 권한 필요 작업을 수행하지 않아야 합니다. 자격 증명, 전체 개인 파일, 모델 추론 또는 제한 없는 인수를 카드에 넣지 마십시오.

반복되는 실패 패턴에 대해 problem-playbook.md을 읽습니다.

각 데이터 소스/작업, 소유 측, 허용된 호출자, 편집, 크기/비율 제한, 실패 모드 및 테스트가 포함된 권한 매트릭스를 생성합니다. 사용자 결과 및 테스트가 없는 권한은 제거됩니다.

5. 변이 프로토콜 적용

Profile/패키지/재시작 변이의 경우 정확히 하나의 작업에 대한 새로운 형식화된 계획을 생성합니다. 다음을 포함합니다:

1. 작업 및 대상 Profile;
2. 변경 불가능한 패키지/소스 ID;
3. 정확한 파일 범위 및 예상 사전 조건 해시;
4. 명령 argv 및 작업 디렉토리;
5. 백업 위치 및 롤백 절차;
6. 사후 조건 및 상태 확인;
7. 하나의 정확한 확인 구문;
8. 만료 및 단일 사용 ID.

계획을 보여주고 정확한 작업별 확인을 기다립니다. 불일치, 만료, 동시 변경 또는 이전 사용 시 무효화합니다. 쓰기 전에 백업, 원자적으로 커밋, 구성 및 런타임 상태 확인 실행, 실패 시 롤백합니다. 리포지토리 릴리스는 로컬 Profile 업데이트를 승인하지 않습니다.

확인 마찰 및 트랜잭션 메커니즘을 명시적 비용으로 취급합니다. R3에 대해 이러한 비용을 수용합니다. 대안은 사용자 상태의 자동, 복구하기 어려운 손상이기 때문입니다. 순수 R0 읽기에 변이 프로토콜을 부과하지 마십시오.

6. 증거 사다리 오르기

현재 증거로만 진행합니다:

• E0: 아이디어 또는 계획.
• E1: 정적 구조/소스 검토.
• E2: 자동화된 단위/계약/결함 테스트.
• E3: 폐기 가능한 Profile 설치, --dump-config, 시작 및 API 스모크.
• E4: 별도로 확인된 실제 Profile 버전, 프로세스/포트, 공식 인벤토리/API 및 가시적인 UI 읽기.
• E5: 외부/공개/장치 승인 및 실패 복구 또는 롤백 증거.

낮은 수준에서 더 높은 수준을 유추하지 마십시오. UI 스크린샷은 롤백을 증명하지 않습니다. HTTP 200은 가시적인 UI를 증명하지 않습니다. 설치 성공은 재시작 상태를 증명하지 않습니다. 시뮬레이터 출력은 실제 장치를 증명하지 않습니다.

Tool 카드의 경우 E2는 결정적 프레젠터, 잘못된 재생, 편집, 범위, 자르기 및 일반 폴백 테스트를 포함합니다. E3는 격리된 DSH 런타임에서 라이브 및 유지된 재생 패리티를 포함합니다. 사용자 Profile에서의 가시적인 카드 동작은 E4로 유지됩니다.

능력별 증거 매트릭스를 생성합니다. 긍정 경로뿐만 아니라 부정 및 복구 증거를 포함합니다. 점수는 준비 상태를 순위를 매깁니다. 권한을 부여하거나 하드 게이트를 대체하지 않습니다.

7. 출시 및 설치 별도로 수행

리포지토리 출시 전에 패키지 버전, README, 카탈로그 항목, 변경 불가능한 설치 앵커, 테스트 및 고정 소스 메타데이터를 동기화합니다. Git 소스의 경우 빌드된 아티팩트를 제공하거나 자체 포함된 prepare 스크립트를 선언하고 pnpm allowBuilds를 공개합니다. 전체 커밋 SHA를 고정합니다.

리포지토리 검사, 소스 확인 및 팩 드라이런을 실행합니다. 병합 후 원격 커밋 및 공개 자산을 확인합니다. 그런 다음 중지합니다. 새로운 확인된 변이 계획에서만 실제 Profile을 업데이트하고 승인된 메커니즘을 통해 재시작한 다음 해결된 버전 및 런타임 상태를 다시 읽습니다.

두 개의 별도 보고서를 생성합니다: 리포지토리 출시 증거 및 Profile/런타임 승인 증거. 두 번째 보고서가 없으면 Profile unchanged 또는 Profile unverified를 명시합니다.

8. 재사용 가능한 플러그인 DSH STORE 준비

재사용 가능한 타사 DSH 플러그인을 빌드하거나, 기존 리포지토리를 DSH STORE에 대해 평가하거나, 카탈로그 항목을 준비할 때마다 marketplace.md를 읽습니다.

제출할 때까지 목록 비호환성을 발견하기 위해 기다리지 마십시오습니다. 첫 번째 스캐폴드부터 고유한 패키지/카탈로그/항목 ID를 예약합니다. 리포지토리, 버전, 라이선스, 안전한 dsh.bundle.patch, 패키지 상대적 패치, 런타임/빌드 파일, 수명 주기 스크립트, 권한, 종속성 및 호환성 증거를 선언합니다. 모든 STORE 평가 시작 시 node scripts/official-dsh-releases.mjs를 실행하고 공식 최신 3개 창을 사용합니다. 기억된 창을 재사용하지 마십시오. 해석기는 가장 높은 활성 npm latest/alpha/beta/rc 채널을 따르고, next 전용 및 사용 중단된 버전을 제외하며, 잘못된 권한에 대해 실패 시 닫힙니다. 관찰된 2026-09-02 창은 0.1.2-alpha.2, 0.1.2-alpha.3, 0.1.2-alpha.4이지만 영구적인 상수가 아닌 증거입니다. 해결된 창의 모든 릴리스에 대해 설치, 시작, 제거 및 롤백에 대한 정확한 compatibility.dshReleases 및 일치하는 compatibility.dshOperations 레코드를 유지합니다. 기록 키는 남을 수 있지만 알 수 없는 메타데이터는 추측 대신 알 수 없음으로 유지됩니다.

STORE 검색과 신뢰할 수 있는 설치를 물리적 및 논리적으로 분리합니다. registry/candidates.json의 레코드는 검색 전용이며 패키지/설치/권한 계약을 전달하지 않으며 installable: false로 정규화되어야 하며 허용된 작업이 없어야 합니다. 별도의 고정 소스, 번들, 라이선스, 권한, 호환성 및 증거 검토 후에만 registry/catalog.json으로 이동할 수 있습니다. 프로모션, 추천, 후원, 별표 또는 화면 녹화는 카탈로그 항목을 대체하지 않습니다.