@captain_z/zsk 1.8.4 → 1.8.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (125) hide show
  1. package/dist/bin.js +13 -0
  2. package/dist/bin.js.map +1 -1
  3. package/dist/commands/check.js +14 -575
  4. package/dist/commands/check.js.map +1 -1
  5. package/dist/commands/config.js +1 -1
  6. package/dist/commands/config.js.map +1 -1
  7. package/dist/commands/demo.d.ts +5 -0
  8. package/dist/commands/demo.js +70 -297
  9. package/dist/commands/demo.js.map +1 -1
  10. package/dist/commands/doctor.js +9 -4
  11. package/dist/commands/doctor.js.map +1 -1
  12. package/dist/commands/gate.d.ts +1 -0
  13. package/dist/commands/gate.js +8 -2
  14. package/dist/commands/gate.js.map +1 -1
  15. package/dist/commands/prepare.js +7 -1
  16. package/dist/commands/prepare.js.map +1 -1
  17. package/dist/commands/project-init.js +30 -8
  18. package/dist/commands/project-init.js.map +1 -1
  19. package/dist/core/config.d.ts +68 -0
  20. package/dist/core/config.js +198 -15
  21. package/dist/core/config.js.map +1 -1
  22. package/dist/core/demo-auth.d.ts +30 -0
  23. package/dist/core/demo-auth.js +213 -0
  24. package/dist/core/demo-auth.js.map +1 -0
  25. package/dist/core/demo-scenarios.d.ts +62 -0
  26. package/dist/core/demo-scenarios.js +276 -0
  27. package/dist/core/demo-scenarios.js.map +1 -0
  28. package/dist/core/demo-sources.d.ts +37 -0
  29. package/dist/core/demo-sources.js +198 -0
  30. package/dist/core/demo-sources.js.map +1 -0
  31. package/dist/core/mcp-registry-discovery.d.ts +16 -0
  32. package/dist/core/mcp-registry-discovery.js +187 -0
  33. package/dist/core/mcp-registry-discovery.js.map +1 -0
  34. package/dist/core/origin-detection.js +1 -1
  35. package/dist/core/origin-detection.js.map +1 -1
  36. package/dist/core/prepare-artifacts.d.ts +16 -0
  37. package/dist/core/prepare-artifacts.js +25 -0
  38. package/dist/core/prepare-artifacts.js.map +1 -0
  39. package/dist/core/prepare-auth-helper.d.ts +8 -0
  40. package/dist/core/prepare-auth-helper.js +32 -0
  41. package/dist/core/prepare-auth-helper.js.map +1 -0
  42. package/dist/core/prepare-materialization.d.ts +8 -0
  43. package/dist/core/prepare-materialization.js +26 -0
  44. package/dist/core/prepare-materialization.js.map +1 -0
  45. package/dist/core/prepare-migration.d.ts +6 -0
  46. package/dist/core/prepare-migration.js +57 -0
  47. package/dist/core/prepare-migration.js.map +1 -0
  48. package/dist/core/prepare-reporting.d.ts +5 -0
  49. package/dist/core/prepare-reporting.js +106 -0
  50. package/dist/core/prepare-reporting.js.map +1 -0
  51. package/dist/core/prepare-routing.d.ts +12 -0
  52. package/dist/core/prepare-routing.js +182 -0
  53. package/dist/core/prepare-routing.js.map +1 -0
  54. package/dist/core/prepare-sync.d.ts +11 -22
  55. package/dist/core/prepare-sync.js +811 -260
  56. package/dist/core/prepare-sync.js.map +1 -1
  57. package/dist/core/prepare-utils.d.ts +6 -0
  58. package/dist/core/prepare-utils.js +35 -0
  59. package/dist/core/prepare-utils.js.map +1 -0
  60. package/dist/core/provider-policy.d.ts +26 -0
  61. package/dist/core/provider-policy.js +180 -0
  62. package/dist/core/provider-policy.js.map +1 -0
  63. package/dist/core/provider-readiness.d.ts +39 -0
  64. package/dist/core/provider-readiness.js +78 -0
  65. package/dist/core/provider-readiness.js.map +1 -0
  66. package/dist/core/source-adapter-normalization.d.ts +31 -0
  67. package/dist/core/source-adapter-normalization.js +235 -0
  68. package/dist/core/source-adapter-normalization.js.map +1 -0
  69. package/dist/core/source-snapshot-adapters.d.ts +3 -3
  70. package/dist/core/source-snapshot-adapters.js +2 -24
  71. package/dist/core/source-snapshot-adapters.js.map +1 -1
  72. package/dist/core/staffing-plan.d.ts +1 -0
  73. package/dist/core/staffing-plan.js +61 -3
  74. package/dist/core/staffing-plan.js.map +1 -1
  75. package/dist/core/stage-clarity-verification.js +21 -18
  76. package/dist/core/stage-clarity-verification.js.map +1 -1
  77. package/dist/core/stage-output-quality.d.ts +3 -0
  78. package/dist/core/stage-output-quality.js +122 -0
  79. package/dist/core/stage-output-quality.js.map +1 -0
  80. package/dist/core/stage-quality-contracts.d.ts +19 -0
  81. package/dist/core/stage-quality-contracts.js.map +1 -1
  82. package/dist/core/stage-quality-criteria.js +0 -37
  83. package/dist/core/stage-quality-criteria.js.map +1 -1
  84. package/dist/core/stage-quality-rendering.d.ts +4 -2
  85. package/dist/core/stage-quality-rendering.js +130 -12
  86. package/dist/core/stage-quality-rendering.js.map +1 -1
  87. package/dist/core/stage-quality.js +17 -6
  88. package/dist/core/stage-quality.js.map +1 -1
  89. package/dist/core/template-registry.js +12 -15
  90. package/dist/core/template-registry.js.map +1 -1
  91. package/dist/core/workspace-conformance.d.ts +39 -0
  92. package/dist/core/workspace-conformance.js +603 -0
  93. package/dist/core/workspace-conformance.js.map +1 -0
  94. package/package.json +2 -2
  95. package/schemas/providers.schema.json +74 -0
  96. package/schemas/zsk-config.schema.json +417 -1
  97. package/templates/project-init/.zsk/README.md +48 -0
  98. package/templates/project-init/.zsk/config.yaml +37 -33
  99. package/templates/project-init/.zsk/docs/CONFIG-SCHEMA.md +127 -0
  100. package/templates/project-init/.zsk/docs/PROJECT-CONFIG.md +26 -21
  101. package/templates/project-init/.zsk/docs/README.md +10 -0
  102. package/templates/project-init/.zsk/docs/SECURITY.md +34 -0
  103. package/templates/project-init/.zsk/docs/SYSTEM-SPEC.md +20 -8
  104. package/templates/project-init/.zsk/evidence/README.md +15 -0
  105. package/templates/project-init/.zsk/issues/README.md +10 -0
  106. package/templates/project-init/.zsk/modules/README.md +19 -0
  107. package/templates/project-init/.zsk/modules/index.md +9 -5
  108. package/templates/project-init/.zsk/raws/README.md +34 -0
  109. package/templates/project-init/.zsk/roles.yaml +36 -105
  110. package/templates/project-init/.zsk/templates/config.examples.yaml +83 -0
  111. package/templates/project-init/.zsk/templates/issue-card.md +23 -0
  112. package/templates/project-init/.zsk/templates/module/README.md +13 -0
  113. package/templates/project-init/.zsk/templates/module/design.md +22 -0
  114. package/templates/project-init/.zsk/templates/module/module.yaml +15 -0
  115. package/templates/project-init/.zsk/templates/module/proposal.md +20 -0
  116. package/templates/project-init/.zsk/templates/module/spec.md +22 -0
  117. package/templates/project-init/.zsk/templates/module/tasks.md +16 -0
  118. package/templates/project-init/.zsk/raws/index.md +0 -34
  119. package/templates/project-init/.zsk/raws/manifest.json +0 -4
  120. package/templates/project-init/.zsk/raws/prepare/backend/index.md +0 -4
  121. package/templates/project-init/.zsk/raws/prepare/design/index.md +0 -21
  122. package/templates/project-init/.zsk/raws/prepare/index.md +0 -37
  123. package/templates/project-init/.zsk/raws/prepare/product/index.md +0 -4
  124. package/templates/project-init/.zsk/raws/prepare/qa/index.md +0 -4
  125. package/templates/project-init/.zsk/raws/prepare/ux/index.md +0 -22
@@ -1,129 +1,60 @@
1
- # ZSK role resource pool.
2
- # Skills dispatch work to these roles as needed; stages and lanes are routing
3
- # hints, not hard limits. Projects may add roles or lane aliases freely.
1
+ # ZSK role pool.
2
+ #
3
+ # This file declares reusable staffing policy. It does not describe a specific
4
+ # run's chosen subagents; dispatch writes run-specific staffing evidence under
5
+ # .zsk/evidence/**.
4
6
 
5
7
  version: 1
6
8
 
7
9
  roles:
8
- lead-integrator:
10
+ leader:
9
11
  subagentType: planner
10
12
  required: true
11
13
  activation: required
12
- reason: Own stage scope, dispatch boundaries, integration, and final evidence.
13
-
14
- product-owner:
15
- subagentType: analyst
16
- stages: [prepare, preproposal, proposal, spec, review, verify, acceptance]
17
- lanes: [product, pm, requirement, requirements, srs, prd]
18
- activation: when product or requirement evidence is configured or in scope
19
- reason: Interpret product scope, requirement semantics, priorities, and acceptance gaps.
20
-
21
- business-analyst:
22
- subagentType: analyst
23
- stages: [preproposal, proposal, spec]
24
- lanes: [business, domain, process, rules]
25
- activation: when domain process or business-rule evidence is configured or in scope
26
- reason: Map domain process, terminology, business rules, and edge cases.
27
-
28
- architect:
29
- subagentType: architect
30
- stages: [preproposal, proposal, spec, design, review]
31
- activation: when architecture, API, system-boundary, or dependency decisions are in scope
32
- reason: Review system boundaries, module relationships, contracts, and technical risks.
33
-
34
- backend-engineer:
35
- subagentType: executor
36
- stages: [prepare, design]
37
- lanes: [backend, api, service, server, repository, repo, repos]
38
- activation: when backend, API, service, repository, or data sources are configured
39
- reason: Inspect backend sources, API contracts, data models, and service-boundary gaps.
40
-
41
- frontend-engineer:
42
- subagentType: executor
43
- stages: [preproposal, design]
44
- lanes: [frontend, web, client, mobile]
45
- activation: when frontend implementation, routing, state, or UI integration is in scope
46
- reason: Map existing UI implementation surfaces, routing, state, candidate page/module-to-code mapping, and component integration risk.
47
-
48
- design-specialist:
49
- subagentType: designer
50
- stages: [prepare, preproposal]
51
- lanes: [design, ui, visual]
52
- activation: when design, UI, visual, prototype, or asset sources are configured
53
- reason: Inspect design assets, screens, visual states, and design-source gaps.
54
-
55
- ux-specialist:
56
- subagentType: designer
57
- stages: [prepare, preproposal]
58
- lanes: [ux, ue, user-experience, research]
59
- activation: when UX, UE, user-flow, or research sources are configured
60
- reason: Inspect user flows, interaction constraints, and usability ambiguity.
61
-
62
- qa-engineer:
63
- subagentType: test-engineer
64
- stages: [prepare, preproposal, spec, task, coding, fix, review, verify]
65
- lanes: [qa, test, testing, quality]
66
- activation: when QA, test, acceptance, or quality evidence is configured or in scope
67
- reason: Connect requirements to acceptance scenarios, test coverage, and verification evidence.
68
-
69
- security-reviewer:
70
- subagentType: security-reviewer
71
- stages: [spec, design, review]
72
- lanes: [security, sec, auth]
73
- activation: when auth, permission, privacy, or data-safety boundaries are in scope
74
- reason: Review trust boundaries, credentials, privacy, and abuse cases.
75
-
76
- operations-engineer:
77
- subagentType: executor
78
- lanes: [ops, devops, release, deploy, platform]
79
- activation: when environment, CI/CD, deployment, or platform risks are configured or in scope
80
- reason: Review release, deployment, rollback, and operational risks.
81
-
82
- auth-fetch-agent:
83
- subagentType: researcher
84
- stages: [prepare]
85
- remoteSources: true
86
- activation: when remote or provider-managed sources are configured
87
- reason: Materialize remote/provider sources through explicit auth, session, and fetch contracts.
14
+ reason: Owns scope, sequencing, integration, and final evidence.
88
15
 
89
16
  researcher:
90
17
  subagentType: researcher
91
18
  stages: [prepare, preproposal]
92
- activation: optional when current official or external evidence is required
93
- reason: Collect official/current external references only when configured local sources are insufficient.
19
+ activation: when current external or provider evidence is required
20
+ reason: Fetches and validates source evidence without owning stage docs.
94
21
 
95
- planner:
96
- subagentType: planner
97
- stages: [preproposal, task]
98
- activation: when task sequencing, dependencies, and risk flags are in scope
99
- reason: Sequence implementation tasks, dependencies, ownership, and evidence hooks.
22
+ architect:
23
+ subagentType: architect
24
+ stages: [proposal, spec, design, review]
25
+ activation: when Module, Interface, Implementation, dependency, or system-boundary decisions are in scope
26
+ reason: Challenges Module/Interface/Implementation fit and long-horizon tradeoffs.
100
27
 
101
28
  executor:
102
29
  subagentType: executor
103
30
  stages: [task, coding, fix]
104
- activation: when implementation ownership, write scope, or scoped code changes are in scope
105
- reason: Implement or estimate scoped code ownership and write boundaries.
31
+ activation: when scoped implementation changes are approved
32
+ reason: Applies bounded implementation changes inside assigned write scopes.
106
33
 
107
- technical-writer:
108
- subagentType: writer
109
- stages: [proposal, archive]
110
- activation: when documentation structure, decision records, or handoff clarity are in scope
111
- reason: Preserve traceable docs, decisions, and reusable learning.
112
-
113
- senior-engineering-reviewer:
34
+ reviewer:
114
35
  subagentType: code-reviewer
115
36
  stages: [review]
116
- activation: when execution-path correctness, maintainability, regressions, or API compatibility need review
117
- reason: Review execution-path correctness, maintainability, regressions, and API boundaries.
118
-
119
- ue-a11y-reviewer:
120
- subagentType: designer
121
- stages: [review]
122
- activation: when UI, UX, accessibility, i18n, or visual behavior is touched
123
- reason: Review UX, accessibility, i18n, and visual impacts when UI is touched.
37
+ activation: when risks, regressions, maintainability, or missing evidence need independent review
38
+ reason: Reviews behavioral risk, regressions, and missing tests or evidence.
124
39
 
125
40
  verifier:
126
41
  subagentType: verifier
127
42
  required: true
128
43
  activation: required
129
- reason: Verify stage outputs against source authority and command evidence.
44
+ reason: Proves completion against acceptance criteria and fresh evidence.
45
+
46
+ # Project-specific examples:
47
+ #
48
+ # issue-curator:
49
+ # extends: reviewer
50
+ # stages: [prepare, triage]
51
+ # resources: [issues]
52
+ # artifacts: [issues]
53
+ # writeScopes:
54
+ # - .zsk/modules/*/_issues/**
55
+ # - .zsk/issues/**
56
+ #
57
+ # confluence-researcher:
58
+ # extends: researcher
59
+ # stages: [prepare]
60
+ # resources: [document]
@@ -0,0 +1,83 @@
1
+ # Example provider/resource/route shapes. Copy only the entries this project
2
+ # actually needs into .zsk/config.yaml.
3
+ #
4
+ # Store secret values in the shell environment, not in config. If credentials
5
+ # live in ~/.zshrc, export them there, for example:
6
+ # export ACCESS_TOKEN=...
7
+ # export CONFLUENCE_USER=...
8
+ # export CONFLUENCE_PASSWORD=...
9
+ # ZSK reads process.env after the shell starts; it does not parse ~/.zshrc.
10
+
11
+ providers:
12
+ jira:
13
+ type: issues
14
+ adapter: jira
15
+ baseUrl: https://jira.example.com
16
+ auth:
17
+ env: ACCESS_TOKEN
18
+ defaults:
19
+ project: ZSK
20
+ assignee: me
21
+ confluence:
22
+ type: document
23
+ adapter: confluence
24
+ baseUrl: https://confluence.example.com
25
+ auth:
26
+ usernameEnv: CONFLUENCE_USER
27
+ passwordEnv: CONFLUENCE_PASSWORD
28
+
29
+ automation:
30
+ demo:
31
+ auth:
32
+ required: true
33
+ loginUrl: http://localhost:3000/login
34
+ storageState: .zsk/modules/{module}/_playwright/.auth/user.json
35
+ envFiles:
36
+ - ~/.zshrc
37
+ env:
38
+ username: DEMO_USERNAME
39
+ password: DEMO_PASSWORD
40
+ selectors:
41
+ username: input[name="username"]
42
+ password: input[type="password"]
43
+ submit: button[type="submit"]
44
+
45
+ resources:
46
+ - id: core-api
47
+ type: repository
48
+ area: Backend Services
49
+ source:
50
+ kind: git-submodule
51
+ path: .zsk/raws/repositories/core-api/repository
52
+
53
+ - id: my-bugs
54
+ type: issues
55
+ provider: jira
56
+ query:
57
+ jql: assignee = currentUser() AND issuetype = Bug ORDER BY updated DESC
58
+ classify:
59
+ by: [priority, component, status]
60
+
61
+ - id: role-prd
62
+ type: document
63
+ area: Confluence
64
+ provider: confluence
65
+ source:
66
+ kind: confluence
67
+ pageId: "12345"
68
+
69
+ - id: public-prd
70
+ type: document
71
+ area: Product
72
+ source:
73
+ kind: url
74
+ url: https://example.com/prd
75
+ fallback:
76
+ acquisition: [playwright_cli]
77
+ observation: [computer_use]
78
+
79
+ routes:
80
+ - from: my-bugs
81
+ to:
82
+ module: permission
83
+ artifact: issues
@@ -0,0 +1,23 @@
1
+ ---
2
+ id: "<issue-id>"
3
+ title: "<issue-title>"
4
+ status: open
5
+ priority: medium
6
+ module: "<module-id>"
7
+ source:
8
+ resource: "<resource-id>"
9
+ provider: "<provider-id>"
10
+ key: "<provider-issue-key>"
11
+ ---
12
+
13
+ # <issue-title>
14
+
15
+ <!-- zsk:source:start -->
16
+ Provider source summary will be updated by `zsk prepare sync`.
17
+ <!-- zsk:source:end -->
18
+
19
+ ## Local Notes
20
+
21
+ ## Decision
22
+
23
+ ## Next Action
@@ -0,0 +1,13 @@
1
+ # Module Template
2
+
3
+ Copy this template through `zsk module init`; do not create real module
4
+ directories by hand unless the same file contract is preserved.
5
+
6
+ Required files:
7
+
8
+ - `module.yaml`
9
+ - `README.md`
10
+ - `proposal.md`
11
+ - `spec.md`
12
+ - `design.md`
13
+ - `tasks.md`
@@ -0,0 +1,22 @@
1
+ # Design
2
+
3
+ ## Output Quality Check
4
+
5
+ status: NEEDS_CLARIFICATION
6
+ owner: design
7
+ source_basis: []
8
+ blocking_items:
9
+ - Map approved behavior to implementation surfaces.
10
+ next_action: Resolve Interface, data flow, rollout, and verification gaps.
11
+
12
+ ## Module
13
+
14
+ ## Interfaces
15
+
16
+ ## Implementation
17
+
18
+ ## Data Flow
19
+
20
+ ## Risks
21
+
22
+ ## Verification
@@ -0,0 +1,15 @@
1
+ # yaml-language-server: $schema=__ZSK_MODULE_SCHEMA_URL__
2
+
3
+ module:
4
+ id: "<module-id>"
5
+ name: "<Module Name>"
6
+
7
+ outputs:
8
+ docs: .zsk/modules/<module-id>
9
+ issues: .zsk/modules/<module-id>/_issues
10
+
11
+ tests:
12
+ raw_cases: []
13
+ derived_cases: []
14
+ automated:
15
+ e2e: []
@@ -0,0 +1,20 @@
1
+ # Proposal
2
+
3
+ ## Output Quality Check
4
+
5
+ status: NEEDS_CLARIFICATION
6
+ owner: proposal
7
+ source_basis: []
8
+ blocking_items:
9
+ - Fill the proposal from reviewed sources.
10
+ next_action: Record scope, non-goals, success criteria, and open questions.
11
+
12
+ ## Problem
13
+
14
+ ## Scope
15
+
16
+ ## Non-Goals
17
+
18
+ ## Success Criteria
19
+
20
+ ## Open Questions
@@ -0,0 +1,22 @@
1
+ # Spec
2
+
3
+ ## Output Quality Check
4
+
5
+ status: NEEDS_CLARIFICATION
6
+ owner: spec
7
+ source_basis: []
8
+ blocking_items:
9
+ - Fill observable behavior and acceptance criteria from reviewed sources.
10
+ next_action: Resolve missing behavior questions before design.
11
+
12
+ ## Functional Requirements
13
+
14
+ ## Non-Functional Requirements
15
+
16
+ ## Acceptance Criteria
17
+
18
+ ## Scenarios
19
+
20
+ ## Edge Cases
21
+
22
+ ## Open Questions
@@ -0,0 +1,16 @@
1
+ # Tasks
2
+
3
+ ## Output Quality Check
4
+
5
+ status: NEEDS_CLARIFICATION
6
+ owner: task
7
+ source_basis: []
8
+ blocking_items:
9
+ - Convert design into executable tasks.
10
+ next_action: Add ordered tasks with dependencies, owners, and evidence hooks.
11
+
12
+ ## Task Queue
13
+
14
+ - [ ] Define the first implementation task.
15
+
16
+ ## Evidence Hooks
@@ -1,34 +0,0 @@
1
- # Raw Source Index
2
-
3
- Immutable fact sources for this project. Generated and refreshed by `zsk prep`.
4
-
5
- Active source snapshots should be organized by prepare responsibility lane:
6
-
7
- - `prepare/product/` for SRS, PRD, business process, acceptance semantics, and work items.
8
- - `prepare/product/{topic}/product-brief.md` and `roadmap.md` for preproposal-generated product direction and MVP/phase decomposition after checkpoint review.
9
- - `prepare/backend/` for backend repositories, API contracts, data model, and service-boundary evidence.
10
- - `prepare/design/` for design/prototype sources, screen maps, and visual assets.
11
- - `prepare/design/{topic}/design-source-needs.md` for preproposal design-source readiness gaps after checkpoint review.
12
- - `prepare/design/{topic}/design-source-map.md` for provider-backed design source coverage and missing Figma/prototype metadata.
13
- - `prepare/ux/` for user flows, interaction notes, IA, and usability evidence.
14
- - `prepare/ux/{topic}/ux-readiness.md` for preproposal journey/flow/IA/readiness seeds after checkpoint review.
15
- - `prepare/ux/{topic}/interaction-handoff.md` for sourced interaction matrices, state coverage, accessibility contract, and unresolved interaction gaps. For module-targeted preproposal work, `{topic}` defaults to the module id.
16
- - `prepare/qa/` for test cases, acceptance scenarios, regression matrices, and QA evidence.
17
-
18
- Interaction handoff files are living raw artifacts owned by `preproposal`, not
19
- inline sections of module `proposal.md` or `design.md`. Downstream module stages
20
- should reference a reviewed revision, for example:
21
-
22
- ```md
23
- Interaction source:
24
- - `.zsk/raws/prepare/ux/{topic}/interaction-handoff.md`
25
- - Accepted revision: <review evidence or commit/date>
26
- ```
27
-
28
- If later UX changes alter scope or behavior, revise the raw artifact first,
29
- record source/status/impact, then route affected module stages back through
30
- `proposal`, `spec`, `design`, or `task` as needed.
31
-
32
- | Provider | Type | Status | Snapshot / Origin |
33
- | --- | --- | --- | --- |
34
- | | | | |
@@ -1,4 +0,0 @@
1
- {
2
- "version": 1,
3
- "resources": []
4
- }
@@ -1,4 +0,0 @@
1
- # Backend Sources
2
-
3
- Backend repositories, API contracts, OpenAPI files, data model notes, auth boundaries, and integration evidence.
4
-
@@ -1,21 +0,0 @@
1
- # Design Sources
2
-
3
- Design handoff files, wireframes, prototype exports, visual assets, design tokens, and platform snapshots.
4
-
5
- Use `prepare/design/{topic}/design-source-map.md` for provider-backed design
6
- sources such as Figma, MasterGo, exports, screenshots, and assets.
7
-
8
- Rules:
9
-
10
- - Preserve provider URL, file/page/frame/node ids, capture method, raw payload,
11
- screenshots/assets, capture time, and tool/auth limits.
12
- - Record prototype links, annotations, variables/tokens, components, variants,
13
- and missing source data when available.
14
- - Treat design files as source evidence, not complete interaction truth.
15
- - Pair source maps with `prepare/ux/{topic}/interaction-handoff.md` when visual
16
- sources need page/module interaction detail.
17
- - For module-targeted preproposal work, `{topic}` defaults to the module id so
18
- the design-source map and interaction handoff can be consumed by the same
19
- module proposal/spec/design chain.
20
- - Code design remains owned by module `design.md`; this lane provides source
21
- evidence and gaps only.
@@ -1,37 +0,0 @@
1
- # Prepare Source Lanes
2
-
3
- Reusable source snapshots for prepare. Iterations and releases should reference these snapshots instead of copying source content.
4
-
5
- ## Responsibility
6
-
7
- `prepare` is the source acquisition and evidence stage. It owns:
8
-
9
- - source origin registration from `.zsk/config.yaml#sources`;
10
- - repository inventory and draft source discovery;
11
- - acquisition planning, blocked-source questions, and correspondence prompts;
12
- - auth preflight and reusable Playwright storageState helpers;
13
- - raw snapshot materialization through local, provider, URL, browser, or
14
- metadata-only strategies;
15
- - `.zsk/raws/manifest.json`, raw indexes, adapter results, and downstream impact
16
- evidence.
17
-
18
- `prepare` does not own product decisions, formal FR/NFR, interaction decisions,
19
- code design, or task planning. If a source is missing or private, preserve the
20
- previous snapshot when present, write a blocked/gap artifact, and route the
21
- missing decision to the owning stage.
22
-
23
- ## Capture Strategy
24
-
25
- Use the least lossy acquisition method that is explicit and repeatable:
26
-
27
- | Source Kind | Preferred Strategy | Notes |
28
- | --- | --- | --- |
29
- | Local docs/contracts/exports | `origin.kind: local` + `zsk prepare sync` | Best default for PRD, API, QA, Figma JSON exports, screenshots, and manually reviewed handoffs. |
30
- | Provider APIs | `origin.provider` + API/export URL + `--allow-network` | Use Confluence/Jira/GitLab/design-source adapters when provider payloads are available. |
31
- | Private web pages | `zsk prepare auth-check`, then `zsk prepare sync --browser --auth-state ... --allow-network` | Browser capture is fallback evidence, not a replacement for provider exports. |
32
- | Repository roots | metadata-only snapshot | Do not crawl broad repositories; configure concrete contracts/files instead. |
33
- | Figma/design URLs | provider export or local raw payload first; browser URL only as fallback | Pair with `prepare/ux/{topic}/interaction-handoff.md` for interaction details. |
34
-
35
- Record incomplete provider coverage as a source gap. A successful prepare run is
36
- allowed to say "blocked" or "needs confirmation"; that is expected behavior, not
37
- a silent failure.
@@ -1,4 +0,0 @@
1
- # Product Sources
2
-
3
- SRS, PRD, business process, acceptance semantics, product decisions, and work items.
4
-
@@ -1,4 +0,0 @@
1
- # QA Sources
2
-
3
- QA cases, acceptance cases, regression matrices, test data, and verification source material.
4
-
@@ -1,22 +0,0 @@
1
- # UX Sources
2
-
3
- User flows, interaction maps, screen behavior notes, usability findings, and experience research artifacts.
4
-
5
- Use `prepare/ux/{topic}/interaction-handoff.md` when UI, UX, or design-source
6
- interaction needs clarification before formal proposal/spec/design work. When
7
- the brief targets a module, `{topic}` defaults to the module id.
8
-
9
- Rules:
10
-
11
- - `preproposal` owns this file as a living source artifact.
12
- - Generate an AI brief from available Figma/design/source/code evidence before
13
- asking humans to fill gaps.
14
- - Separate sourced facts, accepted decisions, inferred assumptions, missing
15
- details, recommended answers, and human confirmation status.
16
- - Record revisions and impact. Downstream module docs consume only reviewed or
17
- accepted revisions.
18
- - For module-targeted work, name the target module, module path, reviewed module
19
- artifacts, scope boundary, terminology alignment, and any page/frame split
20
- rationale in the interaction handoff.
21
- - Do not use this lane for final code design, formal FR/NFR, or task execution
22
- planning.