Engineer SDK
Outcome
Enable a clearly defined capability through the path of least resistance, pain, risk, and effort for the SDK consumer, while keeping the implementation maintainable, testable, secure, configurable, and operationally supportable.
An SDK is a product-facing integration layer that packages the reusable knowledge, protocol details, lifecycle handling, validation, transport behavior, models, errors, and safe defaults required for another party to enable a capability reliably. The consumer may be a customer, client, merchant, partner, application team, developer, or another SDK. Internal modularity is valuable, but it is not the product; the product is the consumer experience and the reliable capability it enables.
Non-negotiable rules
- Consumer first. Write the intended install/start/use example before selecting architecture. Measure complexity from the consumer's point of view, never by repository file count.
- Agnosticism. Assume no language, framework, runtime, source shape, delivery format, package registry, hosting provider, or distribution visibility. Do not assume npm, Maven, NuGet, PyPI, crates.io, a CDN, IIFE, ESM, CommonJS, GitHub, or generated clients. Discover what consumers actually use.
- Version neutrality. Modernization does not inherently mean
v2, semantic versioning, or a major release. Use current contract, target contract, existing implementation, modernized implementation, compatibility layer, and next release until the repository's real versioning policy and the approved compatibility impact are known. Use exact version identifiers only for an existing release, historical evidence, a confirmed target, or an approved migration plan.
- Preserve proven behavior. Inventory public and implicit contracts — including wire encodings, field names, callback timing, error shapes, identities, and state retention — before refactoring. Break a relied-upon contract only through an explicit, reviewed migration decision.
- Evidence before convention. Industry conventions are options to evaluate, not requirements to impose.
- Incremental and reversible. Before editing any live repository, create a feature branch or isolated worktree (after discovering branch protection and governance) — never edit the default branch directly. Work in reviewable phases with explicit gates. Stop for approval at each gate. Preserve user changes and respect repository instructions.
- Proportionality. Internal rigor must not become external friction or repository clutter. Simplification is a scheduled phase, not a suggestion. Proportionality trims unneeded formats and clutter — it is never a reason to deliver below the owner's engineering standard.
- Reference-standard parity. When the owner names a reference implementation, or a sibling SDK in the same product family has reached a higher engineering standard, that standard is the default definition of done (see references/modernization-definition-of-done.md). Stopping short of it requires the owner's explicit, recorded approval — never the agent's own proportionality judgment. Parity binds rigor and verification, not implementation choices: the reference's language, framework, and toolchain are its evidence-driven answers, and this repository's answers still come from its own evidence.
- Phase approval is not operational permission. Approving a gate authorizes only the engineering work described for the next phase. Starting, stopping, installing, or modifying external infrastructure — emulators, simulators, devices, containers, backends, local servers, browsers, system tooling — needs its own explicit approval unless the user's instruction already included it. Before operating such resources, state the execution envelope (what will be started, stopped, installed, changed, or removed); afterwards, report what remains running and what was cleaned up.
Discovery procedure (read-only, always first)
Before proposing any architecture, run a read-only discovery pass and record evidence for:
- Product and consumer — what capability, who integrates it, their skill level, the shortest acceptable happy path, what the consumer must never have to implement, existing consumers/samples/support evidence.
- Runtime and delivery — genuinely supported runtimes; how the SDK is installed, hosted, loaded, linked, or deployed today; which delivery formats are actually needed; whether a registry is involved; whether generated artifacts are committed, published, or consumer-built.
- Standalone or ecosystem-embedded — is this SDK a standalone product consumed directly, or does it plug into a greater ecosystem, framework, or platform whose contracts constrain it (host lifecycle, registration/extension APIs, packaging, review policies, version coupling, distribution channel)? Decide this early: for an embedded SDK the host's rules outrank internal preferences and shape every later phase.
- Current contract — public entry points, configuration, methods, events, callbacks, return values, errors, teardown; relied-upon wire payloads, encodings, URLs, headers, timing, identities, and state; what is validated in a real environment; what is unsafe or accidental.
- Ownership and boundaries — which calls belong in the SDK; which endpoints or credentials vary by deployment; what is baked, configured at startup, or per-operation; what must remain with the backend, host application, OS, or platform provider.
- Engineering and operations — how tests load and whether coverage represents executed source; the exact artifact consumers receive; CI, scanning, release, support, and rollback processes; which documents and scripts are active, generated, obsolete, or historical.
Optionally run scripts/inventory_repo.py to accelerate this (see Scripts below).
If a material answer cannot be discovered and different answers would materially change the architecture, pause and ask a concise question. Never bury an assumption in the implementation.
Reference routing
Read references at these moments; do not read everything up front.
| Reference |
Read when |
| references/sdk-purpose-and-principles.md |
Always, at the start of any engagement |
| references/discovery-and-contracts.md |
Always, before and during discovery and contract freeze |
| references/architecture-and-configuration.md |
When defining boundaries, bootstrap settings, extension points, or endpoint ownership |
| references/compatibility-and-migration.md |
When existing consumers or breaking changes exist, or version impact is discussed |
| references/testing-and-consumer-verification.md |
Before modifying test, build, or release checks |
| references/security-data-and-operations.md |
For sensitive data, authentication, payments, credentials, network calls, or production operations |
| references/documentation-delivery-and-release.md |
When updating consumer docs, artifacts, CI, hosting, or release processes |
| references/platform-profiles.md |
Only the applicable sections, after the runtime and delivery model are confirmed |
| references/modernization-definition-of-done.md |
Always, when the request is modernization or "bring to production standard" — this defines what done means |
| references/case-study-hosted-script-sdk-modernization.md |
When converting a monolith, simplifying an overbuilt plan, preserving an unusual wire contract, or weighing source modularity against delivery simplicity |
Phased workflow and gates
Confirm first whether the request is assessment, planning, creation, modernization, migration, simplification, or release preparation, then run only the phases the request needs. Phase names are portable; the work inside adapts to the repository.
| Phase |
Focus |
Gate (stop for approval) |
| 0 — Intake and evidence |
Discovery, happy-path example, unknowns |
Product boundary, consumer, happy path, delivery model, and change authority understood |
| 1 — Contract and baseline freeze |
Contract inventory and classification, characterization tests, honest baselines |
Behavior comparable objectively before and after changes; coverage verified to measure executed source |
| 2 — Target SDK design |
Consumer path, responsibility matrix, public API, delivery formats, compatibility strategy, phased plan |
Reviewer approves the plan before implementation |
| 3 — Trustworthy foundation |
Real test loading, build/lint/static checks, actual-artifact verification, CI |
Clean checkout reproduces and verifies the deliverable |
| 4 — Internal restructuring |
Responsibility seams behind the frozen contract |
Characterization and consumer tests pass through new internals |
| 5 — Contract and configurability |
Approved surface, error model, encapsulated calls, layered configuration, protected invariants |
Representative consumers enable the capability without editing SDK source |
| 6 — Integration proof and docs |
Consumer integration tests on the exact deliverable, aligned documentation |
Docs describe the shipped contract; shortest path works from a clean consumer |
| 7 — Delivery and operational readiness |
Channel-appropriate release checks, real-platform validation, failure-cause classification |
Exact candidate is releasable, supportable, recoverable |
| 8 — Retrospective simplification |
Remove clutter, relocate planning evidence, re-verify |
Every remaining file has a current purpose, owner, and verification path |
Details for each phase live in the routed references. Do not pull speculative later-phase work into an earlier phase.
At every gate, report four things before stopping: what was delivered; the remaining phase roadmap; what the next approval unlocks; and the current delta against the definition of done (and the reference/sibling standard where one exists) — in both directions: areas still below the bar, and anything added that the reference lacks, each such excess citing its own consumer or operator evidence. A paused engagement must never be mistakable for a finished one, and no phase may be marked complete while its area is below the definition-of-done bar without recorded owner approval. Repository-hygiene violations (committed coverage output, generated doc byproducts, planning artifacts inside the product repo) appear in every gate report as failures until resolved or owner-approved — they are never deferred silently to Phase 8. Gate approval carries no operational permission (rule 9): if the next phase needs external infrastructure, name it in the gate report and get it approved separately.
Responsibility and configuration decisions
For each capability, classify ownership explicitly: Encapsulate, Configure, Per operation, Optional adapter, Consumer-owned, Backend/platform-owned, or Do not support. Evaluate configuration layers in order: safe SDK defaults → owner/product baked configuration → consumer startup configuration → per-operation values → explicit per-call controls. Every configurable option must document who sets it, when it resolves, its default, validation, mutability, log safety, protected-field interaction, and compatibility effect. Full procedure: references/architecture-and-configuration.md.
Scripts
scripts/ contains parameterized, dependency-light Python 3 (standard library only) validation tools. They are optional aids: run one only when its concern applies to the engagement, and configure it via a project config file (copy assets/templates/sdk-skill-config.example.json). An absent config section means "not selected," never "failed."
| Script |
Use for |
inventory_repo.py |
Read-only evidence inventory during Phase 0 |
check_boundaries.py |
Enforcing configured dependency/global/platform ownership rules |
check_artifacts.py |
Deliverable existence, size budgets, checksums, optional smoke command |
check_generated.py |
Stale committed generated artifacts |
check_metadata.py |
Version/metadata agreement across manifests, sources, changelogs |
check_docs.py |
Links, version references, retired terminology, required examples |
run_consumer_checks.py |
Isolated temporary-consumer install/build/load smoke checks |
Safety rules: all support --help and an explicit repository root; all are read-only except an explicit temporary/output directory; none touch the network unless the caller explicitly enables it; command execution requires an explicit opt-in flag; non-zero exit means a failed assertion, not a missing configuration. Run <script> --help before first use.
"Optional" means the concern may not apply — never that a selected concern may go unverified. Once a concern applies to the engagement (artifacts, boundaries, metadata, docs, generated files, consumer checks), verify it with the bundled script or a project-native equivalent, and name which one in the gate report. A selected concern with neither is a gate failure, not a judgment call.
Required outputs
Create only the artifacts the requested work needs. Candidates (templates in assets/templates/): current-state assessment, consumer happy-path example, public/implicit contract inventory, responsibility matrix, architecture decisions with rejected alternatives, phased plan with gates, per-phase review notes, migration map, final readiness and simplification review, and consumer-facing docs appropriate to the actual delivery model.
Planning and retrospective artifacts do not automatically belong in the SDK product repository — ask where they belong. Product repositories should contain only material the selected operating model genuinely requires.
Proportionality and cleanup gate
At the end of planning and after every material phase, ask:
- Does this exist because the consumer or operator needs it?
- Is it required by the selected delivery model?
- Is it actively verified?
- Is there a simpler design that preserves the same guarantees?
- Can a directory, compatibility layer, package format, script, document, or dependency now be removed?
- Where a reference implementation exists: for everything this repository ships that the reference does not, re-ask question 1 against that specific addition — matching the reference is not evidence, and neither is having already built it.
Re-run this gate whenever a delivery assumption changes.
Conflict precedence
When guidance conflicts, surface the conflict and apply, in order: (1) legal, safety, protocol-integrity, and security constraints; (2) verified external system and consumer contracts; (3) explicit current product scope and delivery requirements; (4) proven public behavior and migration cost; (5) repository and organizational operating constraints; (6) measured maintainability, performance, and support needs; (7) general conventions and aesthetics. Never silently override a higher-order constraint — record the decision, evidence, consequences, and migration impact. Later verified information supersedes earlier assumptions; keep both in history, only the current decision in active guidance.
Final verification and handoff
Before declaring any engagement complete:
- Re-run the full verification suite after cleanup, against the exact consumer deliverable.
- Confirm documentation, examples, and versions describe the shipped contract.
- Confirm release-number advice follows the project's actual versioning policy and the approved compatibility impact.
- Distinguish code failures from CI runner, permissions, queue, or provider failures before changing code in response to a red check.
- Record reusable lessons separately from product-specific exceptions, and place planning evidence where the user directs.
- Stop for explicit approval before publication, tagging, or declaring stability.
1---2name: engineer-sdk3description: Assess, design, create, modernize, migrate, simplify, validate, document, or release software development kits across languages, frameworks, platforms, source shapes, and delivery models. Use when turning existing code into an SDK, upgrading an SDK to production standard, designing configurable integration APIs, preserving compatibility, improving SDK architecture or developer experience, or preparing an SDK for supported release. Also use when a user mentions client libraries, wrappers, integration layers, API packaging, or making code reusable for merchants, partners, or other teams, even if they never say "SDK".4---56# Engineer SDK78## Outcome910Enable a clearly defined capability through the path of least resistance, pain, risk, and effort for the SDK consumer, while keeping the implementation maintainable, testable, secure, configurable, and operationally supportable.1112An SDK is a product-facing integration layer that packages the reusable knowledge, protocol details, lifecycle handling, validation, transport behavior, models, errors, and safe defaults required for another party to enable a capability reliably. The consumer may be a customer, client, merchant, partner, application team, developer, or another SDK. Internal modularity is valuable, but it is not the product; the product is the consumer experience and the reliable capability it enables.1314## Non-negotiable rules15161. **Consumer first.** Write the intended install/start/use example before selecting architecture. Measure complexity from the consumer's point of view, never by repository file count.172. **Agnosticism.** Assume no language, framework, runtime, source shape, delivery format, package registry, hosting provider, or distribution visibility. Do not assume npm, Maven, NuGet, PyPI, crates.io, a CDN, IIFE, ESM, CommonJS, GitHub, or generated clients. Discover what consumers actually use.183. **Version neutrality.** Modernization does not inherently mean `v2`, semantic versioning, or a major release. Use *current contract*, *target contract*, *existing implementation*, *modernized implementation*, *compatibility layer*, and *next release* until the repository's real versioning policy and the approved compatibility impact are known. Use exact version identifiers only for an existing release, historical evidence, a confirmed target, or an approved migration plan.194. **Preserve proven behavior.** Inventory public and implicit contracts — including wire encodings, field names, callback timing, error shapes, identities, and state retention — before refactoring. Break a relied-upon contract only through an explicit, reviewed migration decision.205. **Evidence before convention.** Industry conventions are options to evaluate, not requirements to impose.216. **Incremental and reversible.** Before editing any live repository, create a feature branch or isolated worktree (after discovering branch protection and governance) — never edit the default branch directly. Work in reviewable phases with explicit gates. Stop for approval at each gate. Preserve user changes and respect repository instructions.227. **Proportionality.** Internal rigor must not become external friction or repository clutter. Simplification is a scheduled phase, not a suggestion. Proportionality trims unneeded formats and clutter — it is never a reason to deliver below the owner's engineering standard.238. **Reference-standard parity.** When the owner names a reference implementation, or a sibling SDK in the same product family has reached a higher engineering standard, that standard is the default definition of done (see [references/modernization-definition-of-done.md](references/modernization-definition-of-done.md)). Stopping short of it requires the owner's explicit, recorded approval — never the agent's own proportionality judgment. Parity binds rigor and verification, not implementation choices: the reference's language, framework, and toolchain are its evidence-driven answers, and this repository's answers still come from its own evidence.249. **Phase approval is not operational permission.** Approving a gate authorizes only the engineering work described for the next phase. Starting, stopping, installing, or modifying external infrastructure — emulators, simulators, devices, containers, backends, local servers, browsers, system tooling — needs its own explicit approval unless the user's instruction already included it. Before operating such resources, state the execution envelope (what will be started, stopped, installed, changed, or removed); afterwards, report what remains running and what was cleaned up.2526## Discovery procedure (read-only, always first)2728Before proposing any architecture, run a read-only discovery pass and record evidence for:2930- **Product and consumer** — what capability, who integrates it, their skill level, the shortest acceptable happy path, what the consumer must never have to implement, existing consumers/samples/support evidence.31- **Runtime and delivery** — genuinely supported runtimes; how the SDK is installed, hosted, loaded, linked, or deployed today; which delivery formats are actually needed; whether a registry is involved; whether generated artifacts are committed, published, or consumer-built.32- **Standalone or ecosystem-embedded** — is this SDK a standalone product consumed directly, or does it plug into a greater ecosystem, framework, or platform whose contracts constrain it (host lifecycle, registration/extension APIs, packaging, review policies, version coupling, distribution channel)? Decide this early: for an embedded SDK the host's rules outrank internal preferences and shape every later phase.33- **Current contract** — public entry points, configuration, methods, events, callbacks, return values, errors, teardown; relied-upon wire payloads, encodings, URLs, headers, timing, identities, and state; what is validated in a real environment; what is unsafe or accidental.34- **Ownership and boundaries** — which calls belong in the SDK; which endpoints or credentials vary by deployment; what is baked, configured at startup, or per-operation; what must remain with the backend, host application, OS, or platform provider.35- **Engineering and operations** — how tests load and whether coverage represents executed source; the exact artifact consumers receive; CI, scanning, release, support, and rollback processes; which documents and scripts are active, generated, obsolete, or historical.3637Optionally run `scripts/inventory_repo.py` to accelerate this (see Scripts below).3839If a material answer cannot be discovered and different answers would materially change the architecture, pause and ask a concise question. Never bury an assumption in the implementation.4041## Reference routing4243Read references at these moments; do not read everything up front.4445| Reference | Read when |46|---|---|47| [references/sdk-purpose-and-principles.md](references/sdk-purpose-and-principles.md) | Always, at the start of any engagement |48| [references/discovery-and-contracts.md](references/discovery-and-contracts.md) | Always, before and during discovery and contract freeze |49| [references/architecture-and-configuration.md](references/architecture-and-configuration.md) | When defining boundaries, bootstrap settings, extension points, or endpoint ownership |50| [references/compatibility-and-migration.md](references/compatibility-and-migration.md) | When existing consumers or breaking changes exist, or version impact is discussed |51| [references/testing-and-consumer-verification.md](references/testing-and-consumer-verification.md) | Before modifying test, build, or release checks |52| [references/security-data-and-operations.md](references/security-data-and-operations.md) | For sensitive data, authentication, payments, credentials, network calls, or production operations |53| [references/documentation-delivery-and-release.md](references/documentation-delivery-and-release.md) | When updating consumer docs, artifacts, CI, hosting, or release processes |54| [references/platform-profiles.md](references/platform-profiles.md) | Only the applicable sections, after the runtime and delivery model are confirmed |55| [references/modernization-definition-of-done.md](references/modernization-definition-of-done.md) | Always, when the request is modernization or "bring to production standard" — this defines what done means |56| [references/case-study-hosted-script-sdk-modernization.md](references/case-study-hosted-script-sdk-modernization.md) | When converting a monolith, simplifying an overbuilt plan, preserving an unusual wire contract, or weighing source modularity against delivery simplicity |5758## Phased workflow and gates5960Confirm first whether the request is assessment, planning, creation, modernization, migration, simplification, or release preparation, then run only the phases the request needs. Phase names are portable; the work inside adapts to the repository.6162| Phase | Focus | Gate (stop for approval) |63|---|---|---|64| 0 — Intake and evidence | Discovery, happy-path example, unknowns | Product boundary, consumer, happy path, delivery model, and change authority understood |65| 1 — Contract and baseline freeze | Contract inventory and classification, characterization tests, honest baselines | Behavior comparable objectively before and after changes; coverage verified to measure executed source |66| 2 — Target SDK design | Consumer path, responsibility matrix, public API, delivery formats, compatibility strategy, phased plan | Reviewer approves the plan before implementation |67| 3 — Trustworthy foundation | Real test loading, build/lint/static checks, actual-artifact verification, CI | Clean checkout reproduces and verifies the deliverable |68| 4 — Internal restructuring | Responsibility seams behind the frozen contract | Characterization and consumer tests pass through new internals |69| 5 — Contract and configurability | Approved surface, error model, encapsulated calls, layered configuration, protected invariants | Representative consumers enable the capability without editing SDK source |70| 6 — Integration proof and docs | Consumer integration tests on the exact deliverable, aligned documentation | Docs describe the shipped contract; shortest path works from a clean consumer |71| 7 — Delivery and operational readiness | Channel-appropriate release checks, real-platform validation, failure-cause classification | Exact candidate is releasable, supportable, recoverable |72| 8 — Retrospective simplification | Remove clutter, relocate planning evidence, re-verify | Every remaining file has a current purpose, owner, and verification path |7374Details for each phase live in the routed references. Do not pull speculative later-phase work into an earlier phase.7576At **every** gate, report four things before stopping: what was delivered; the remaining phase roadmap; what the next approval unlocks; and the current delta against the definition of done (and the reference/sibling standard where one exists) — **in both directions**: areas still below the bar, and anything added that the reference lacks, each such excess citing its own consumer or operator evidence. A paused engagement must never be mistakable for a finished one, and no phase may be marked complete while its area is below the definition-of-done bar without recorded owner approval. Repository-hygiene violations (committed coverage output, generated doc byproducts, planning artifacts inside the product repo) appear in **every** gate report as failures until resolved or owner-approved — they are never deferred silently to Phase 8. Gate approval carries no operational permission (rule 9): if the next phase needs external infrastructure, name it in the gate report and get it approved separately.7778## Responsibility and configuration decisions7980For each capability, classify ownership explicitly: **Encapsulate**, **Configure**, **Per operation**, **Optional adapter**, **Consumer-owned**, **Backend/platform-owned**, or **Do not support**. Evaluate configuration layers in order: safe SDK defaults → owner/product baked configuration → consumer startup configuration → per-operation values → explicit per-call controls. Every configurable option must document who sets it, when it resolves, its default, validation, mutability, log safety, protected-field interaction, and compatibility effect. Full procedure: [references/architecture-and-configuration.md](references/architecture-and-configuration.md).8182## Scripts8384`scripts/` contains parameterized, dependency-light Python 3 (standard library only) validation tools. They are optional aids: run one only when its concern applies to the engagement, and configure it via a project config file (copy [assets/templates/sdk-skill-config.example.json](assets/templates/sdk-skill-config.example.json)). An absent config section means "not selected," never "failed."8586| Script | Use for |87|---|---|88| `inventory_repo.py` | Read-only evidence inventory during Phase 0 |89| `check_boundaries.py` | Enforcing configured dependency/global/platform ownership rules |90| `check_artifacts.py` | Deliverable existence, size budgets, checksums, optional smoke command |91| `check_generated.py` | Stale committed generated artifacts |92| `check_metadata.py` | Version/metadata agreement across manifests, sources, changelogs |93| `check_docs.py` | Links, version references, retired terminology, required examples |94| `run_consumer_checks.py` | Isolated temporary-consumer install/build/load smoke checks |9596Safety rules: all support `--help` and an explicit repository root; all are read-only except an explicit temporary/output directory; none touch the network unless the caller explicitly enables it; command execution requires an explicit opt-in flag; non-zero exit means a failed assertion, not a missing configuration. Run `<script> --help` before first use.9798"Optional" means the *concern* may not apply — never that a selected concern may go unverified. Once a concern applies to the engagement (artifacts, boundaries, metadata, docs, generated files, consumer checks), verify it with the bundled script or a project-native equivalent, and name which one in the gate report. A selected concern with neither is a gate failure, not a judgment call.99100## Required outputs101102Create only the artifacts the requested work needs. Candidates (templates in `assets/templates/`): current-state assessment, consumer happy-path example, public/implicit contract inventory, responsibility matrix, architecture decisions with rejected alternatives, phased plan with gates, per-phase review notes, migration map, final readiness and simplification review, and consumer-facing docs appropriate to the actual delivery model.103104Planning and retrospective artifacts do not automatically belong in the SDK product repository — ask where they belong. Product repositories should contain only material the selected operating model genuinely requires.105106## Proportionality and cleanup gate107108At the end of planning and after every material phase, ask:1091101. Does this exist because the consumer or operator needs it?1112. Is it required by the selected delivery model?1123. Is it actively verified?1134. Is there a simpler design that preserves the same guarantees?1145. Can a directory, compatibility layer, package format, script, document, or dependency now be removed?1156. Where a reference implementation exists: for everything this repository ships that the reference does not, re-ask question 1 against that specific addition — matching the reference is not evidence, and neither is having already built it.116117Re-run this gate whenever a delivery assumption changes.118119## Conflict precedence120121When guidance conflicts, surface the conflict and apply, in order: (1) legal, safety, protocol-integrity, and security constraints; (2) verified external system and consumer contracts; (3) explicit current product scope and delivery requirements; (4) proven public behavior and migration cost; (5) repository and organizational operating constraints; (6) measured maintainability, performance, and support needs; (7) general conventions and aesthetics. Never silently override a higher-order constraint — record the decision, evidence, consequences, and migration impact. Later verified information supersedes earlier assumptions; keep both in history, only the current decision in active guidance.122123## Final verification and handoff124125Before declaring any engagement complete:126127- Re-run the full verification suite after cleanup, against the exact consumer deliverable.128- Confirm documentation, examples, and versions describe the shipped contract.129- Confirm release-number advice follows the project's actual versioning policy and the approved compatibility impact.130- Distinguish code failures from CI runner, permissions, queue, or provider failures before changing code in response to a red check.131- Record reusable lessons separately from product-specific exceptions, and place planning evidence where the user directs.132- Stop for explicit approval before publication, tagging, or declaring stability.
Veritas-Quaesitor