diff --git a/documentation/openspec/changes/add-eu-digital-markets-act-regulation-skill/tasks.md b/documentation/openspec/changes/add-eu-digital-markets-act-regulation-skill/tasks.md index c6871278..8b5c8741 100644 --- a/documentation/openspec/changes/add-eu-digital-markets-act-regulation-skill/tasks.md +++ b/documentation/openspec/changes/add-eu-digital-markets-act-regulation-skill/tasks.md @@ -6,21 +6,22 @@ - [x] 1.2 Confirm `801-regulations-eu-ai-act`, `802-regulations-dora`, and `803-regulations-gdpr` are already covered and the Digital Markets Act remains pending. - [x] 1.3 Create a per-regulation OpenSpec change for the Digital Markets Act. - [x] 1.4 Record source artifacts, derivation direction, scope boundary, and validation expectations. -- [ ] 1.5 Add `skills-generator/src/main/resources/skill-indexes/808-skill.xml`. -- [ ] 1.6 Add `skills-generator/src/main/resources/skill-references/808-regulations-eu-digital-markets-act-chapters-summary.xml` with direct official-source chapter links and article mapping in the same style as `804-regulations-eu-nis2-chapters-summary.xml`. -- [ ] 1.7 Add `skills-generator/src/main/resources/skill-references/808-regulations-eu-digital-markets-act-engineering-examples.xml` with Java-focused examples and output guidance. -- [ ] 1.8 Add `skills-generator/src/main/resources/skill-references/assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md` with a potential violation or non-compliance table that includes reference area and associated official-source link columns. -- [ ] 1.9 Include engineering controls for interoperability interfaces, data access APIs, consent and preference evidence, ranking and self-preferencing audit signals, business-user export workflows, anti-circumvention guardrails, access control, observability, change control, documentation, and compliance evidence handoff. -- [ ] 1.10 Update `808-skill.xml` so the workflow reads chapter summary, engineering examples, and report template before implementation review. -- [ ] 1.11 Register skill id `808` with explicit `skillId="808-regulations-eu-digital-markets-act"`, references, and report template resource in `skills-generator/src/main/resources/skills.xml`. -- [ ] 1.12 Add `skills-generator/src/test/resources/gherkin/808-regulations-eu-digital-markets-act.feature` with pull-request and direct-to-main acceptance scenarios modeled after `801-804`. -- [ ] 1.13 Ensure the Gherkin scenarios require reading the chapters summary, engineering examples, and report template, and require linked violation mapping in generated reports. -- [ ] 1.14 Add Digital Markets Act report examples under `examples/regulations/eu-digital-markets-act`. -- [ ] 1.15 Add `808-regulations-eu-digital-markets-act` to `skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md`. -- [ ] 1.16 Validate changed XML files with `xmllint --noout`. -- [ ] 1.17 Run `./mvnw clean install -pl skills-generator`. -- [ ] 1.18 Inspect generated local `.agents/skills/808-regulations-eu-digital-markets-act/SKILL.md`. -- [ ] 1.19 Inspect generated local chapters summary, engineering examples, and report template outputs. -- [ ] 1.20 Execute the listed `808-regulations-eu-digital-markets-act` acceptance prompt and verify it passes. -- [ ] 1.21 Run `./mvnw clean verify -pl skills-generator`. -- [ ] 1.22 Run `openspec validate --all`. +- [x] 1.5 Add `skills-generator/src/main/resources/skill-indexes/808-skill.xml`. +- [x] 1.6 Add `skills-generator/src/main/resources/skill-references/808-regulations-eu-digital-markets-act-chapters-summary.xml` with direct official-source chapter links and article mapping in the same style as `804-regulations-eu-nis2-chapters-summary.xml`. +- [x] 1.7 Add `skills-generator/src/main/resources/skill-references/808-regulations-eu-digital-markets-act-engineering-examples.xml` with Java-focused examples and output guidance. +- [x] 1.8 Add `skills-generator/src/main/resources/skill-references/assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md` with a potential violation or non-compliance table that includes reference area and associated official-source link columns. +- [x] 1.9 Include engineering controls for interoperability interfaces, data access APIs, consent and preference evidence, ranking and self-preferencing audit signals, business-user export workflows, anti-circumvention guardrails, access control, observability, change control, documentation, and compliance evidence handoff. +- [x] 1.10 Update `808-skill.xml` so the workflow reads chapter summary, engineering examples, and report template before implementation review. +- [x] 1.11 Register skill id `808` with explicit `skillId="808-regulations-eu-digital-markets-act"`, references, and report template resource in `skills-generator/src/main/resources/skills.xml`. +- [x] 1.12 Add `skills-generator/src/test/resources/gherkin/808-regulations-eu-digital-markets-act.feature` with pull-request and direct-to-main acceptance scenarios modeled after `801-804`. +- [x] 1.13 Ensure the Gherkin scenarios require reading the chapters summary, engineering examples, and report template, and require linked violation mapping in generated reports. +- [x] 1.14 Add Digital Markets Act report examples under `examples/regulations/eu-digital-markets-act`. +- [x] 1.15 Add `808-regulations-eu-digital-markets-act` to `skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md`. +- [x] 1.16 Validate changed XML files with `xmllint --noout`. +- [x] 1.17 Run `./mvnw clean install -pl skills-generator`. +- [x] 1.18 Inspect generated local `.agents/skills/808-regulations-eu-digital-markets-act/SKILL.md`. +- [x] 1.19 Inspect generated local chapters summary, engineering examples, and report template outputs. +- [x] 1.20 Execute the listed `808-regulations-eu-digital-markets-act` acceptance prompt and verify it passes. + - Manual coverage recorded with `examples/regulations/eu-digital-markets-act/DMA-ENGINEERING-REVIEW-REPORT.md` and `examples/regulations/eu-digital-markets-act/DMA-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md`; no automated acceptance runner exists beyond the documented prompt inventory. +- [x] 1.21 Run `./mvnw clean verify -pl skills-generator`. +- [x] 1.22 Run `openspec validate --all`. diff --git a/examples/regulations/eu-digital-markets-act/DMA-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md b/examples/regulations/eu-digital-markets-act/DMA-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md new file mode 100644 index 00000000..bef3ddeb --- /dev/null +++ b/examples/regulations/eu-digital-markets-act/DMA-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md @@ -0,0 +1,222 @@ +# EU Digital Markets Act Engineering Review Report + +Use this report as engineering evidence for legal, compliance, platform governance, product, privacy, security, risk, competition, executive accountability, architecture, and business-owner review. + +This report is not legal advice. It identifies engineering controls and escalation points from the reviewed direct-to-main delivery evidence. Gatekeeper designation, core platform service scope, obligation applicability, consent interpretation, self-preferencing assessments, fair access terms, suspension or exemption questions, and regulatory interpretation require qualified owner review. + +## 1. Review Context + +- System or service name: CheckoutService delivery instructions change +- Repository, product, platform, or business service: Fictional Java Quarkus ecommerce platform with direct commits to `main` +- Review date: 2026-06-14 +- Reviewers: AI-assisted EU Digital Markets Act engineering review +- Business owner: Not identified in reviewed evidence +- Technical owner: Software engineers, tech leads, and platform engineers are described, but no named CheckoutService owner is identified +- Platform owner: Platform engineers are described, but no named platform owner is identified +- Product owner: Not identified in reviewed evidence +- Data owner: Not identified in reviewed evidence +- Privacy owner: Not identified in reviewed evidence +- Security owner: Not identified in reviewed evidence +- Legal/compliance owner: Not identified in reviewed evidence +- Source materials reviewed: + - `examples/diagrams/deployment/system-example-cicd-model.md` + - `examples/diagrams/deployment/expected-system-deployment.puml` + - `examples/diagrams/deployment/checkout-service-feature-request.md` + - `.agents/skills/808-regulations-eu-digital-markets-act/references/808-regulations-eu-digital-markets-act-chapters-summary.md` + - `.agents/skills/808-regulations-eu-digital-markets-act/references/808-regulations-eu-digital-markets-act-engineering-examples.md` + - `.agents/skills/808-regulations-eu-digital-markets-act/assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md` + +## 2. Platform And Core Service Context + +- Service description: CheckoutService coordinates checkout saga steps for price validation, inventory reservation, payment authorization, order creation, delivery slot booking, PostgreSQL order state, saga state, and Kafka events. +- Possible core platform service signal: The evidence describes a customer-facing ecommerce platform with storefront, catalog, search, cart, checkout, delivery, identity, payment gateway integration, Kafka, and business delivery workflows. It does not confirm a DMA core platform service classification. +- Possible gatekeeper-scope signal: No gatekeeper designation, listed core platform service, active business-user count, active end-user count, or Commission designation evidence is present. +- Business-user journey: Not explicitly described. The platform may include sellers, advertisers, or third-party merchants, but the reviewed files only describe shoppers and internal teams. +- End-user journey: Shoppers authenticate, browse products, add products to cart, check out, pay, book delivery slots, and receive notifications. +- Deployment geography: Azure production environment is described; EU user geography and Member State scope are not specified. +- Environments in scope: Development, test, staging, and production. +- Platform dependencies: Azure Front Door, WAF, AKS, PostgreSQL, Kafka, Key Vault, Azure Monitor, App Insights, Log Analytics, Backup Vault, Artifactory, Docker registry, external identity provider, external payment gateway, and email/SMS provider. +- Open applicability questions: + - Is the ecommerce platform part of a designated gatekeeper core platform service? + - Does direct-to-main delivery provide enough evidence for DMA-sensitive changes to ranking, data access, consent, exports, interoperability, or platform defaults? + - Are search, ranking, marketplace, advertising, identity, or payment-support features subject to DMA owner review? + - Which legal, compliance, platform governance, product, privacy, security, risk, competition, and executive owners must approve residual DMA risk? + +## 3. DMA Engineering Scope + +- Applications, APIs, jobs, and batch workloads: Web storefront BFF, API gateway, identity, catalog, search, cart, pricing, CheckoutService, payment adapter, inventory, delivery slot, notification worker, analytics pipeline, checkout saga logic, and deployment workflows. +- Data stores, queues, topics, indexes, and caches: User Profile DB, Product DB, Search Index, Cart DB, Pricing DB, Order DB, Saga Support PostgreSQL, Inventory DB, Delivery DB, Kafka topics `order.created`, `payment.authorized`, `stock.reserved`, `slot.booked`, `delivery.slot.requested`, `order.confirmed`, and compensation events. +- Business-user data access APIs: Not present in reviewed evidence. +- End-user portability or preference workflows: Not present in reviewed evidence. +- Interoperability interfaces: Kafka events and service-to-service lookup are described for internal services; third-party interoperability interfaces are not present. +- Ranking, search, recommendation, or advertising systems: Catalog and search services are described, but ranking policies, self-preferencing audit signals, and advertising metrics are not present. +- Consent, preference, and identity flows: Identity provider integration is described. Consent and preference evidence for data combination, delivery preferences, or data sharing is not present. +- Marketplace, app-store, browser, operating-system, messaging, cloud, or advertising features: Cloud-hosted ecommerce and search features are described. No app-store, browser, operating-system, messaging interoperability, or advertising transparency workflow is present. +- IAM, secrets, keys, and privileged operations: Azure Key Vault, managed identities, API gateway authentication, payment tokens, idempotency keys, database credentials, Kafka credentials, and deployment credentials. +- CI/CD workflows and deployment paths: Direct commit to `main`, main branch CI, Artifactory, Docker registry, signed images, SBOM and provenance metadata, GitOps/CD pipeline, automated environment promotion, migration safety checks, health checks, and smoke tests. +- Monitoring, alerting, and observability systems: Azure Monitor, App Insights, Log Analytics, structured logs, metrics, traces, correlation IDs, dashboards, alerts, health checks, and smoke tests. +- Documentation, compliance reports, and owner handoff records: Not present as DMA-specific records. + +## 4. Potential Violation Or Non-Compliance Mapping + +This section is not a legal finding. It lists concrete potential DMA violation or non-compliance signals from the reviewed direct-to-main delivery evidence and routes each item to qualified owner review. No violation is confirmed by this engineering review. + +| Potential violation or non-compliance signal | DMA reference area | Associated official-source link | Evidence from reviewed system | Current status | Required owner review | Engineering action | +| -------------------------------------------- | ------------------ | ------------------------------- | ----------------------------- | -------------- | --------------------- | ------------------ | +| Unclear gatekeeper or core platform service scope | Applicability / designation / service listing | [Chapter I](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_I), [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_II), [Annex](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#anx) | Ecommerce production platform, search, identity, payment, delivery, and cloud-hosted services are described, but no designation or service-classification evidence is recorded | Potential gap | Legal / compliance / platform governance / product | Record qualified owner decision on gatekeeper and core platform service scope before applying DMA-specific release gates | +| Missing pre-merge review for DMA-sensitive change | Compliance demonstration / change control | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III), [Chapter V](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_V) | Engineers commit directly to `main`; the feature modifies order database structure and Kafka event data | Potential gap | Platform / security / compliance / architecture / risk owner | Require pre-commit or pre-merge review gate for database migrations, Kafka contracts, privacy-sensitive fields, platform access, ranking, consent, export, and interoperability changes | +| Protected-main bypass or insufficient approval evidence | Anti-circumvention / release governance / evidence handoff | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | The reviewed delivery path is `commit + push directly to main`; no protected-main rule, approval requirement, or exception workflow is shown | Potential gap | Platform governance / security / executive accountability owner | Enforce branch protection or equivalent signed approval workflow before production release | +| Missing business-user data access and export evidence | Business-user data access / data portability | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | No business-user portal, data access API, export workflow, or authorised third-party access evidence is present | Potential gap | Product / data owner / compliance / privacy | If business users are in scope, define data access API contracts, export formats, consent boundaries, audit logs, and support workflow | +| Missing interoperability evidence | Interoperability / effective access / security preservation | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | Internal Kafka and service lookup are described, but no external interoperability request workflow, reference offer, or third-party compatibility evidence exists | Potential gap | Platform / security / compliance | Determine whether interoperability obligations are relevant; if so, document interface contracts, request handling, security controls, compatibility tests, and degradation monitoring | +| Missing consent and preference evidence | Consent / personal-data combination / preference handling | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | Delivery preferences and identity integration are described; no consent ledger, withdrawal evidence, neutral UI review, or purpose-bound data-sharing evidence is shown | Potential gap | Privacy / legal / product | Add consent and preference evidence where platform data is combined, cross-used, shared, or used for advertising, identity, or delivery preferences | +| Missing ranking or self-preferencing audit signals | Ranking / fair and non-discriminatory treatment / own-service treatment | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | Search service exists, but ranking policy version, own-service flags, experiments, sponsored placement, and fairness checks are not described | Potential gap | Product / competition / compliance / architecture | Add ranking audit events, policy versioning, experiment evidence, own-service treatment checks, and qualified self-preferencing review | +| Weak anti-circumvention evidence | Anti-circumvention / non-neutral choice / degraded quality / service fragmentation | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | Feature adds delivery instruction storage and Kafka schema changes; no DMA-specific review verifies that choices, access, exports, or interoperability are not degraded | Potential gap | Legal / compliance / platform governance / product | Add DMA review to release gates for ranking, access, consent, data export, interoperability, platform-default, and service-boundary changes | + +## 5. Engineering Controls + +- Pre-commit review and main-branch protection: Replace direct-to-main release eligibility for DMA-sensitive changes with branch protection, required review, signed approval, or equivalent auditable control before production deployment. +- Interoperability interfaces: If third-party interoperability is in scope, publish versioned API contracts, request workflow, security model, compatibility tests, degradation checks, and audit events. +- Data access APIs: Define business-user and authorised-third-party access scopes, dataset lineage, personal-data boundaries, authorization, rate limits, export formats, error handling, and audit records. +- Business-user export workflows: Avoid manual database extracts. Provide request status, delivery channel, retention period, support path, schema version, and failure alerts. +- End-user portability workflows: If in scope, document export formats, continuous access where required, identity verification, privacy checks, and delivery evidence. +- Consent and preference evidence: Preserve specific opt-in, withdrawal, prompt history, retry suppression, neutral UI review, purpose binding, and privacy/legal owner handoff where data is combined or shared. +- Ranking and self-preferencing audit signals: Add ranking policy versions, experiment IDs, own-service result counts, third-party result counts, sponsored placement counts, fairness checks, and review triggers. +- Advertising transparency metrics: If ads are in scope, record advertiser and publisher metrics, fee data, measurement-tool access, authorization, and data-sharing consent boundaries. +- Fair and non-discriminatory access terms: Record access terms, termination conditions, exceptions, business-user communications, and dispute or support workflows. +- Anti-circumvention guardrails: Block designs that fragment service scope, make choices hard to exercise, degrade quality for users exercising rights, hide exports, or use UI design to subvert autonomy. +- Access control and least privilege: Verify field-level authorization for full delivery notes, business-user scopes, service-to-service lookup, Kafka publishing, Key Vault access, and observability writes. +- Evidence-safe logging: Exclude `delivery_instruction_note` from logs and Kafka payloads. Preserve correlation IDs, schema versions, order IDs, saga IDs, export job IDs, and audit event IDs. +- Monitoring, metrics, traces, and alerting: Add alerts for export failures, access-denied spikes, interoperability error rates, schema compatibility failures, ranking policy changes, consent ledger failures, and Kafka publish failures. +- Documentation and runbooks: Add runbooks for DMA evidence handoff, export support, interoperability request handling, ranking review, consent evidence, direct-to-main exceptions, and release approvals. +- Change control and release gates: Require database migration tests, Kafka contract tests, privacy-safe logging tests, schema version compatibility tests, architecture review, and qualified owner review before direct-to-main changes can reach production. +- Compliance evidence handoff: Create a release evidence packet with source files reviewed, owner decisions, unresolved scope questions, API contracts, audit dashboards, branch-protection or exception evidence, and residual risk decisions. + +Example direct-to-main anti-circumvention release gate: + +```java +ReleaseDecision evaluateDirectMainDmaRelease(DmaEngineeringReview review) { + var blockers = new ArrayList(); + requirePassing(review.mainBranchProtection(), "protected-main or equivalent approval control", blockers); + requirePresent(review.preCommitPlatformReview(), "pre-commit platform compliance review", blockers); + requirePresent(review.corePlatformServiceScope(), "core platform service scope evidence", blockers); + requirePresent(review.dataAccessApiEvidence(), "business-user data access evidence", blockers); + requirePassing(review.consentPreferenceAudit(), "consent and preference audit evidence", blockers); + requirePassing(review.rankingFairnessReview(), "ranking and self-preferencing review", blockers); + requirePresent(review.complianceHandoff(), "qualified owner handoff", blockers); + return blockers.isEmpty() + ? ReleaseDecision.approvedWithEvidence(review.serviceId(), review.evidenceReferences(), review.approvers()) + : ReleaseDecision.blocked(review.serviceId(), blockers, Escalation.required("legal", "compliance", "platform-governance", "product", "privacy", "security", "risk")); +} +``` + +Example business-user export audit control: + +```java +ExportJob scheduleBusinessUserExport(BusinessUserDataRequest request) { + accessPolicy.requireBusinessUserScope(request.businessUserId(), request.requestedBy()); + ExportJob job = exportJobs.schedule(request.businessUserId(), request.datasetId(), request.format()); + auditLog.record(DmaExportAuditEvent.scheduled(request.businessUserId(), request.datasetId(), job.id())); + return job; +} +``` + +Example ranking audit control: + +```java +rankingAudit.record(new RankingAuditEvent( + request.requestId(), + context.rankingPolicyVersion(), + results.ownServiceResultCount(), + results.thirdPartyResultCount(), + fairnessChecks.evaluate(results).status() +)); +``` + +## 6. Evidence Inventory + +- Core platform service inventory: Not present. +- Business-user and end-user journey map: End-user shopper journey is present; business-user journey is not present. +- Active-user metric methodology: Not present. +- Interoperability interface contract: Not present for external interoperability. +- Data access API contract: Not present. +- Export workflow runbook: Not present. +- Consent and preference records: Not present. +- Ranking audit events: Not present. +- Advertising or search data evidence: Search service is described; search data access and advertising transparency evidence are not present. +- Access-control policy: API gateway authentication, managed identities, Key Vault, and private networking are described; DMA-specific business-user access policy is not present. +- Monitoring dashboards: Azure Monitor, App Insights, Log Analytics, dashboards, logs, traces, metrics, and alerts are described; dashboard IDs and DMA-specific alerts are not present. +- Alert routing: Not present. +- Compliance report or summary: Not present. +- Change approval: Direct commits to `main` and main branch CI are described; explicit pre-merge review, protected-main approval, or DMA approval for the feature request is not present. +- Release decision: Not present. + +## 7. Residual Risks + +- Residual risk: Direct-to-main delivery may allow a database migration, Kafka contract change, privacy-sensitive field change, ranking change, data access API change, export change, or interoperability change to reach production without independent review. +- Impact: Customer-facing disruption, unapproved data propagation, incomplete rollback planning, weak DMA evidence, and late compliance escalation. +- Likelihood: Medium, because the reviewed delivery model commits every change directly to `main`. +- Mitigation: Require protected-main rules or equivalent approval controls, pre-commit review evidence, emergency exception process, and release gates for migration, Kafka, privacy, data access, ranking, export, and interoperability changes. +- Owner: Platform governance owner, security owner, architecture owner, CheckoutService owner, and executive accountability owner. +- Acceptance decision: Required before production release. +- Review date: Before the direct-to-main commit is eligible for deployment. + +- Residual risk: DMA applicability and core platform service scope are unknown. +- Impact: Controls may be over-applied, under-applied, or escalated too late if the ecommerce platform is part of a designated gatekeeper service. +- Likelihood: Unknown. +- Mitigation: Route gatekeeper designation, listed service scope, business-user role, end-user geography, and obligation applicability to legal, compliance, platform governance, product, and competition owners. +- Owner: Legal/compliance owner and platform governance owner. +- Acceptance decision: Required before relying on this report for production compliance decisions. +- Review date: Before production release if DMA scope is plausible. + +- Residual risk: Delivery instructions may create data sharing, preference, and access-control evidence gaps. +- Impact: Over-broad event propagation, unclear preference handling, personal-data exposure, and weak business-user or support access controls. +- Likelihood: Medium, because the feature explicitly adds optional free text and changes Kafka events. +- Mitigation: Exclude notes from Kafka and logs, add field-level authorization, record preference handling, define service-to-service lookup controls, and review retention rules. +- Owner: CheckoutService owner, privacy owner, security owner, and data owner. +- Acceptance decision: Required before production release. +- Review date: Before committing to `main` and before production deployment. + +## 8. Release Decision + +- Decision: Blocked for production until direct-to-main risk is replaced by protected approval evidence and platform-scope evidence is attached to the release record. +- Conditions: + - Protected-main or equivalent pre-commit approval evidence is recorded. + - Qualified owners confirm whether the platform is in DMA gatekeeper or core platform service scope. + - Business-user data access, export, ranking, and interoperability applicability are explicitly recorded. + - Database migration tests prove nullable/default behavior and rollback or forward-fix readiness. + - Kafka contract tests prove schema version 3 compatibility and older-consumer tolerance. + - Privacy-safe logging tests prove `delivery_instruction_note` is not logged or emitted through Kafka. + - Access-control tests prove full delivery notes are available only through authorised service-to-service lookup. + - Monitoring covers schema failures, export/access failures if applicable, delivery note lookup failures, and direct-to-main exception alerts. +- Blockers: + - Direct commits to `main` are the described change path. + - No named legal/compliance, platform governance, product, privacy, security, or data owner. + - No DMA scope decision or owner handoff. + - No business-user data access, export, ranking, or interoperability evidence where those concerns may apply. +- Required approvals: Legal/compliance, platform governance, product, privacy, security, architecture, service owner, and executive accountability owner. +- Expiry or review date: Re-review when platform scope, search/ranking, advertising, business-user access, interoperability, consent, export, or delivery-instruction data flows change. +- Environments approved: Development and test only until owner handoff and direct-to-main controls are complete. +- Emergency rollback path: Previous validated image plus database forward-fix or rollback plan and Kafka schema compatibility checks. + +## 9. Action Plan + +| Priority | Action | Owner | Due date | Evidence expected | Status | +| -------- | ------ | ----- | -------- | ----------------- | ------ | +| High | Replace direct-to-main release eligibility with protected-main, required review, or equivalent signed approval evidence for DMA-sensitive changes | Platform governance and security owners | Before production release | Branch rule, approval record, or exception workflow | Open | +| High | Record DMA scope decision for gatekeeper, core platform service, business-user role, and affected obligations | Legal/compliance and platform governance | Before production release | Owner decision record linked to release | Open | +| High | Add privacy-safe logging, field-level authorization, migration, and Kafka contract tests for delivery instructions | CheckoutService and security owners | Before commit eligibility | Test results and release evidence | Open | +| Medium | Define business-user data access, export, ranking, and interoperability applicability for the ecommerce platform | Product, data, architecture, and compliance owners | Before release readiness | Applicability matrix and evidence inventory | Open | +| Medium | Add observability for direct-to-main exceptions, delivery note lookup, Kafka schema errors, export/access failures if applicable, and audit events | Platform and operations owners | Before production deployment | Dashboard IDs and alert rules | Open | +| Low | Create DMA evidence handoff runbook for future platform-scope changes | Compliance and platform owners | Next compliance planning cycle | Runbook and evidence repository path | Open | + +## 10. Final Notes + +- Items requiring legal interpretation: Gatekeeper designation, core platform service classification, obligation applicability, fair access terms, and regulatory interpretation. +- Items requiring platform governance decision: Whether direct-to-main can be used for DMA-sensitive platform changes and whether checkout, search, identity, payment-support, marketplace, or cloud-hosted services are part of a listed core platform service. +- Items requiring product decision: Business-user journey, export expectations, preference UX, ranking policy review, and platform access terms. +- Items requiring privacy or consent review: Delivery instruction note, data sharing, data combination, opt-in requirements, preference history, and retention. +- Items requiring security exception: Direct-to-main production eligibility is not approved by this report. +- Items requiring architecture decision: Kafka schema versioning, delivery-note lookup boundary, interoperability applicability, and data access API design. +- Items requiring competition or compliance review: Self-preferencing assessment, business-user access conditions, and DMA report evidence. +- Items requiring business acceptance: Release conditions and residual risk. +- Next review trigger: Any change to platform scope, business-user access, ranking, advertising, interoperability, consent, export, direct-to-main policy, or delivery-instruction data flows. diff --git a/examples/regulations/eu-digital-markets-act/DMA-ENGINEERING-REVIEW-REPORT.md b/examples/regulations/eu-digital-markets-act/DMA-ENGINEERING-REVIEW-REPORT.md new file mode 100644 index 00000000..730ced96 --- /dev/null +++ b/examples/regulations/eu-digital-markets-act/DMA-ENGINEERING-REVIEW-REPORT.md @@ -0,0 +1,220 @@ +# EU Digital Markets Act Engineering Review Report + +Use this report as engineering evidence for legal, compliance, platform governance, product, privacy, security, risk, competition, executive accountability, architecture, and business-owner review. + +This report is not legal advice. It identifies engineering controls and escalation points from the reviewed system evidence. Gatekeeper designation, core platform service scope, obligation applicability, consent interpretation, self-preferencing assessments, fair access terms, suspension or exemption questions, and regulatory interpretation require qualified owner review. + +## 1. Review Context + +- System or service name: CheckoutService delivery instructions change +- Repository, product, platform, or business service: Fictional Java Quarkus ecommerce platform +- Review date: 2026-06-14 +- Reviewers: AI-assisted EU Digital Markets Act engineering review +- Business owner: Not identified in reviewed evidence +- Technical owner: Software engineers, tech leads, reviewers, and platform engineers are described, but no named CheckoutService owner is identified +- Platform owner: Platform engineers are described, but no named platform owner is identified +- Product owner: Not identified in reviewed evidence +- Data owner: Not identified in reviewed evidence +- Privacy owner: Not identified in reviewed evidence +- Security owner: Not identified in reviewed evidence +- Legal/compliance owner: Not identified in reviewed evidence +- Source materials reviewed: + - `examples/diagrams/deployment/system-example-cicd-pr-model.md` + - `examples/diagrams/deployment/expected-system-deployment.puml` + - `examples/diagrams/deployment/checkout-service-feature-request.md` + - `.agents/skills/808-regulations-eu-digital-markets-act/references/808-regulations-eu-digital-markets-act-chapters-summary.md` + - `.agents/skills/808-regulations-eu-digital-markets-act/references/808-regulations-eu-digital-markets-act-engineering-examples.md` + - `.agents/skills/808-regulations-eu-digital-markets-act/assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md` + +## 2. Platform And Core Service Context + +- Service description: CheckoutService coordinates checkout saga steps for price validation, inventory reservation, payment authorization, order creation, delivery slot booking, PostgreSQL order state, saga state, and Kafka events. +- Possible core platform service signal: The evidence describes a customer-facing ecommerce platform with storefront, catalog, search, cart, checkout, delivery, identity, payment gateway integration, Kafka, and business delivery workflows. It does not confirm a DMA core platform service classification such as online intermediation, app store, search engine, social network, browser, operating system, messaging, cloud, or advertising service. +- Possible gatekeeper-scope signal: No gatekeeper designation, listed core platform service, active business-user count, active end-user count, or Commission designation evidence is present. +- Business-user journey: Not explicitly described. The platform may include sellers, advertisers, or third-party merchants, but the reviewed files only describe shoppers and internal teams. +- End-user journey: Shoppers authenticate, browse products, add products to cart, check out, pay, book delivery slots, and receive notifications. +- Deployment geography: Azure production environment is described; EU user geography and Member State scope are not specified. +- Environments in scope: Development, test, staging, and production. +- Platform dependencies: Azure Front Door, WAF, AKS, PostgreSQL, Kafka, Key Vault, Azure Monitor, App Insights, Log Analytics, Backup Vault, Artifactory, Docker registry, external identity provider, external payment gateway, and email/SMS provider. +- Open applicability questions: + - Is the ecommerce platform part of a designated gatekeeper core platform service? + - Does the platform act as an online intermediation service for business users selling to end users? + - Are search, ranking, marketplace, advertising, identity, or payment-support features subject to DMA owner review? + - Which legal, compliance, platform governance, product, privacy, security, risk, and competition owners must approve residual DMA risk? + +## 3. DMA Engineering Scope + +- Applications, APIs, jobs, and batch workloads: Web storefront BFF, API gateway, identity, catalog, search, cart, pricing, CheckoutService, payment adapter, inventory, delivery slot, notification worker, analytics pipeline, checkout saga logic, and deployment workflows. +- Data stores, queues, topics, indexes, and caches: User Profile DB, Product DB, Search Index, Cart DB, Pricing DB, Order DB, Saga Support PostgreSQL, Inventory DB, Delivery DB, Kafka topics `order.created`, `payment.authorized`, `stock.reserved`, `slot.booked`, `delivery.slot.requested`, `order.confirmed`, and compensation events. +- Business-user data access APIs: Not present in reviewed evidence. +- End-user portability or preference workflows: Not present in reviewed evidence. +- Interoperability interfaces: Kafka events and service-to-service lookup are described for internal services; third-party interoperability interfaces are not present. +- Ranking, search, recommendation, or advertising systems: Catalog and search services are described, but ranking policies, self-preferencing audit signals, and advertising metrics are not present. +- Consent, preference, and identity flows: Identity provider integration is described. Consent and preference evidence for data combination, delivery preferences, or data sharing is not present. +- Marketplace, app-store, browser, operating-system, messaging, cloud, or advertising features: Cloud-hosted ecommerce and search features are described. No app-store, browser, operating-system, messaging interoperability, or advertising transparency workflow is present. +- IAM, secrets, keys, and privileged operations: Azure Key Vault, managed identities, API gateway authentication, payment tokens, idempotency keys, database credentials, Kafka credentials, and deployment credentials. +- CI/CD workflows and deployment paths: Short-lived branch, pull request review and checks, CI/CD pipeline, Artifactory, Docker registry, signed images, SBOM and provenance metadata, GitOps/CD pipeline, automated environment promotion, migration safety checks, health checks, and smoke tests. +- Monitoring, alerting, and observability systems: Azure Monitor, App Insights, Log Analytics, structured logs, metrics, traces, correlation IDs, dashboards, alerts, health checks, and smoke tests. +- Documentation, compliance reports, and owner handoff records: Not present as DMA-specific records. + +## 4. Potential Violation Or Non-Compliance Mapping + +This section is not a legal finding. It lists concrete potential DMA violation or non-compliance signals from the reviewed delivery evidence and routes each item to qualified owner review. No violation is confirmed by this engineering review. + +| Potential violation or non-compliance signal | DMA reference area | Associated official-source link | Evidence from reviewed system | Current status | Required owner review | Engineering action | +| -------------------------------------------- | ------------------ | ------------------------------- | ----------------------------- | -------------- | --------------------- | ------------------ | +| Unclear gatekeeper or core platform service scope | Applicability / designation / service listing | [Chapter I](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_I), [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_II), [Annex](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#anx) | Ecommerce production platform, search, identity, payment, delivery, and cloud-hosted services are described, but no designation or service-classification evidence is recorded | Potential gap | Legal / compliance / platform governance / product | Record qualified owner decision on gatekeeper and core platform service scope before applying DMA-specific release gates | +| Missing business-user data access and export evidence | Business-user data access / data portability | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | No business-user portal, data access API, export workflow, or authorised third-party access evidence is present | Potential gap | Product / data owner / compliance / privacy | If business users are in scope, define data access API contracts, export formats, consent boundaries, audit logs, and support workflow | +| Missing interoperability evidence | Interoperability / effective access / security preservation | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | Internal Kafka and service lookup are described, but no external interoperability request workflow, reference offer, or third-party compatibility evidence exists | Potential gap | Platform / security / compliance | Determine whether interoperability obligations are relevant; if so, document interface contracts, request handling, security controls, compatibility tests, and degradation monitoring | +| Missing consent and preference evidence | Consent / personal-data combination / preference handling | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | Delivery preferences and identity integration are described; no consent ledger, withdrawal evidence, neutral UI review, or purpose-bound data-sharing evidence is shown | Potential gap | Privacy / legal / product | Add consent and preference evidence where platform data is combined, cross-used, shared, or used for advertising, identity, or delivery preferences | +| Missing ranking or self-preferencing audit signals | Ranking / fair and non-discriminatory treatment / own-service treatment | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | Search service exists, but ranking policy version, own-service flags, experiments, sponsored placement, and fairness checks are not described | Potential gap | Product / competition / compliance / architecture | Add ranking audit events, policy versioning, experiment evidence, own-service treatment checks, and qualified self-preferencing review | +| Weak anti-circumvention and change-control evidence | Anti-circumvention / non-neutral choice / degraded quality / service fragmentation | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | Feature adds delivery instruction storage and Kafka schema changes; no DMA-specific review verifies that choices, access, exports, or interoperability are not degraded | Potential gap | Legal / compliance / platform governance / product | Add DMA review to release gates for ranking, access, consent, data export, interoperability, platform-default, and service-boundary changes | +| Incomplete compliance evidence handoff | Compliance demonstration / reporting / monitoring | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III), [Chapter V](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_V) | Logs, metrics, traces, SBOM, provenance, and deployment evidence are described, but no DMA compliance report, owner handoff, or evidence repository is present | Potential gap | Compliance / security / risk / executive accountability | Create evidence inventory for APIs, data flows, rankings, consent, exports, releases, and owner decisions | + +## 5. Engineering Controls + +- Interoperability interfaces: If third-party interoperability is in scope, publish versioned API contracts, request workflow, security model, compatibility tests, degradation checks, and audit events. +- Data access APIs: Define business-user and authorised-third-party access scopes, dataset lineage, personal-data boundaries, authorization, rate limits, export formats, error handling, and audit records. +- Business-user export workflows: Avoid manual database extracts. Provide request status, delivery channel, retention period, support path, schema version, and failure alerts. +- End-user portability workflows: If in scope, document export formats, continuous access where required, identity verification, privacy checks, and delivery evidence. +- Consent and preference evidence: Preserve specific opt-in, withdrawal, prompt history, retry suppression, neutral UI review, purpose binding, and privacy/legal owner handoff where data is combined or shared. +- Ranking and self-preferencing audit signals: Add ranking policy versions, experiment IDs, own-service result counts, third-party result counts, sponsored placement counts, fairness checks, and review triggers. +- Advertising transparency metrics: If ads are in scope, record advertiser and publisher metrics, fee data, measurement-tool access, authorization, and data-sharing consent boundaries. +- Fair and non-discriminatory access terms: Record access terms, termination conditions, exceptions, business-user communications, and dispute or support workflows. +- Anti-circumvention guardrails: Block designs that fragment service scope, make choices hard to exercise, degrade quality for users exercising rights, hide exports, or use UI design to subvert autonomy. +- Access control and least privilege: Verify field-level authorization for full delivery notes, business-user scopes, service-to-service lookup, Kafka publishing, Key Vault access, and observability writes. +- Evidence-safe logging: Exclude `delivery_instruction_note` from logs and Kafka payloads. Preserve correlation IDs, schema versions, order IDs, saga IDs, export job IDs, and audit event IDs. +- Monitoring, metrics, traces, and alerting: Add alerts for export failures, access-denied spikes, interoperability error rates, schema compatibility failures, ranking policy changes, consent ledger failures, and Kafka publish failures. +- Documentation and runbooks: Add runbooks for DMA evidence handoff, export support, interoperability request handling, ranking review, consent evidence, and release exceptions. +- Change control and release gates: Require pull request review, database migration tests, Kafka contract tests, privacy-safe logging tests, schema version compatibility tests, and qualified owner review for platform-scope changes. +- Compliance evidence handoff: Create a release evidence packet with source files reviewed, owner decisions, unresolved scope questions, API contracts, audit dashboards, and residual risk decisions. + +Example business-user data access control: + +```java +BusinessUserDataExport createExport(BusinessUserDataRequest request) { + accessPolicy.requireBusinessUserScope(request.businessUserId(), request.requestedBy()); + dataCatalog.requireDocumentedLineage(request.datasetId(), "DMA business-user data access"); + if (request.includesPersonalData()) { + consentLedger.requireOptIn(request.endUserId(), request.businessUserId(), ConsentPurpose.BUSINESS_USER_DATA_SHARING); + } + ExportJob job = exportJobs.scheduleContinuousExport(request.businessUserId(), request.datasetId(), request.format()); + auditLog.record(DmaDataAccessAuditEvent.created(request.businessUserId(), request.datasetId(), job.id())); + return BusinessUserDataExport.accepted(job.id(), job.statusUrl()); +} +``` + +Example ranking audit control: + +```java +rankingAudit.record(new RankingAuditEvent( + request.requestId(), + context.rankingPolicyVersion(), + results.ownServiceResultCount(), + results.thirdPartyResultCount(), + fairnessChecks.evaluate(results).status() +)); +``` + +Example anti-circumvention release gate: + +```java +ReleaseDecision evaluate(DmaEngineeringReview review) { + var blockers = new ArrayList(); + requirePresent(review.corePlatformServiceScope(), "core platform service scope evidence", blockers); + requirePassing(review.interoperabilityContractTests(), "interoperability contract tests", blockers); + requirePresent(review.dataAccessApiEvidence(), "business-user data access evidence", blockers); + requirePassing(review.consentPreferenceAudit(), "consent and preference audit evidence", blockers); + requirePassing(review.rankingFairnessReview(), "ranking and self-preferencing review", blockers); + requirePresent(review.complianceHandoff(), "qualified owner handoff", blockers); + return blockers.isEmpty() + ? ReleaseDecision.approvedWithEvidence(review.serviceId(), review.evidenceReferences(), review.approvers()) + : ReleaseDecision.blocked(review.serviceId(), blockers, Escalation.required("legal", "compliance", "platform-governance", "product", "privacy", "security", "risk")); +} +``` + +## 6. Evidence Inventory + +- Core platform service inventory: Not present. +- Business-user and end-user journey map: End-user shopper journey is present; business-user journey is not present. +- Active-user metric methodology: Not present. +- Interoperability interface contract: Not present for external interoperability. +- Data access API contract: Not present. +- Export workflow runbook: Not present. +- Consent and preference records: Not present. +- Ranking audit events: Not present. +- Advertising or search data evidence: Search service is described; search data access and advertising transparency evidence are not present. +- Access-control policy: API gateway authentication, managed identities, Key Vault, and private networking are described; DMA-specific business-user access policy is not present. +- Monitoring dashboards: Azure Monitor, App Insights, Log Analytics, dashboards, logs, traces, metrics, and alerts are described; dashboard IDs and DMA-specific alerts are not present. +- Alert routing: Not present. +- Compliance report or summary: Not present. +- Change approval: Pull request review and checks are described; explicit DMA review is not present. +- Release decision: Not present. + +## 7. Residual Risks + +- Residual risk: DMA applicability and core platform service scope are unknown. +- Impact: Controls may be over-applied, under-applied, or escalated too late if the ecommerce platform is part of a designated gatekeeper service. +- Likelihood: Unknown. +- Mitigation: Route gatekeeper designation, listed service scope, business-user role, end-user geography, and obligation applicability to legal, compliance, platform governance, product, and competition owners. +- Owner: Legal/compliance owner and platform governance owner. +- Acceptance decision: Required before relying on this report for production compliance decisions. +- Review date: Before production release if DMA scope is plausible. + +- Residual risk: Delivery instructions may create data sharing, preference, and access-control evidence gaps. +- Impact: Over-broad event propagation, unclear preference handling, personal-data exposure, and weak business-user or support access controls. +- Likelihood: Medium, because the feature explicitly adds optional free text and changes Kafka events. +- Mitigation: Exclude notes from Kafka and logs, add field-level authorization, record preference handling, define service-to-service lookup controls, and review retention rules. +- Owner: CheckoutService owner, privacy owner, security owner, and data owner. +- Acceptance decision: Required before production release. +- Review date: During PR review and release readiness. + +- Residual risk: Database migration and Kafka schema change may affect platform evidence and downstream services. +- Impact: Checkout disruption, incompatible consumers, incomplete observability, and weak release evidence for platform-scope controls. +- Likelihood: Medium. +- Mitigation: Require migration approval, Kafka schema compatibility tests, rollback or forward-fix plan, consumer readiness evidence, and post-deployment monitoring. +- Owner: Architecture owner, platform owner, CheckoutService owner, and downstream service owners. +- Acceptance decision: Required before production release. +- Review date: During PR review and release readiness. + +## 8. Release Decision + +- Decision: Conditionally blocked for production until platform-scope and privacy/security evidence is attached to the PR and release record. +- Conditions: + - Qualified owners confirm whether the platform is in DMA gatekeeper or core platform service scope. + - Business-user data access, export, ranking, and interoperability applicability are explicitly recorded. + - Database migration tests prove nullable/default behavior and rollback or forward-fix readiness. + - Kafka contract tests prove schema version 3 compatibility and older-consumer tolerance. + - Privacy-safe logging tests prove `delivery_instruction_note` is not logged or emitted through Kafka. + - Access-control tests prove full delivery notes are available only through authorised service-to-service lookup. + - Monitoring covers schema failures, export/access failures if applicable, and delivery note lookup failures. +- Blockers: + - No named legal/compliance, platform governance, product, privacy, security, or data owner. + - No DMA scope decision or owner handoff. + - No business-user data access, export, ranking, or interoperability evidence where those concerns may apply. +- Required approvals: Legal/compliance, platform governance, product, privacy, security, architecture, and service owner. +- Expiry or review date: Re-review when platform scope, search/ranking, advertising, business-user access, interoperability, or delivery-instruction data flows change. +- Environments approved: Development and test only until owner handoff is complete. +- Emergency rollback path: Previous validated image plus database forward-fix or rollback plan and Kafka schema compatibility checks. + +## 9. Action Plan + +| Priority | Action | Owner | Due date | Evidence expected | Status | +| -------- | ------ | ----- | -------- | ----------------- | ------ | +| High | Record DMA scope decision for gatekeeper, core platform service, business-user role, and affected obligations | Legal/compliance and platform governance | Before production release | Owner decision record linked to release | Open | +| High | Add privacy-safe logging, field-level authorization, migration, and Kafka contract tests for delivery instructions | CheckoutService and security owners | Before merge | Test results and PR evidence | Open | +| Medium | Define business-user data access, export, ranking, and interoperability applicability for the ecommerce platform | Product, data, architecture, and compliance owners | Before release readiness | Applicability matrix and evidence inventory | Open | +| Medium | Add observability for delivery note lookup, Kafka schema errors, export/access failures if applicable, and audit events | Platform and operations owners | Before production deployment | Dashboard IDs and alert rules | Open | +| Low | Create DMA evidence handoff runbook for future platform-scope changes | Compliance and platform owners | Next compliance planning cycle | Runbook and evidence repository path | Open | + +## 10. Final Notes + +- Items requiring legal interpretation: Gatekeeper designation, core platform service classification, obligation applicability, fair access terms, and regulatory interpretation. +- Items requiring platform governance decision: Whether checkout, search, identity, payment-support, marketplace, or cloud-hosted services are part of a listed core platform service. +- Items requiring product decision: Business-user journey, export expectations, preference UX, ranking policy review, and platform access terms. +- Items requiring privacy or consent review: Delivery instruction note, data sharing, data combination, opt-in requirements, preference history, and retention. +- Items requiring security exception: None approved by this report. +- Items requiring architecture decision: Kafka schema versioning, delivery-note lookup boundary, interoperability applicability, and data access API design. +- Items requiring competition or compliance review: Self-preferencing assessment, business-user access conditions, and DMA report evidence. +- Items requiring business acceptance: Release conditions and residual risk. +- Next review trigger: Any change to platform scope, business-user access, ranking, advertising, interoperability, consent, export, or delivery-instruction data flows. diff --git a/skills-generator/src/main/resources/skill-indexes/808-skill.xml b/skills-generator/src/main/resources/skill-indexes/808-skill.xml new file mode 100644 index 00000000..83e2575e --- /dev/null +++ b/skills-generator/src/main/resources/skill-indexes/808-skill.xml @@ -0,0 +1,88 @@ + + + + Juan Antonio Breña Moral + 0.16.0-SNAPSHOT + Apache-2.0 + Use when reviewing, designing, or modifying Java enterprise systems that may support EU Digital Markets Act gatekeeper-platform concerns, core platform services, interoperability, business-user data access, consent-dependent data combination, ranking, self-preferencing, advertising transparency, or anti-circumvention controls. This should trigger for requests such as Review a Java platform for DMA controls; Design interoperability and business-user data access evidence; Add ranking, consent, preference, or anti-circumvention audit controls; Assess gatekeeper-platform engineering evidence before production release. + + + EU Digital Markets Act Regulation for Java Enterprise Gatekeeper Platform Controls + When does a Java enterprise platform require DMA-aware gatekeeper controls, and what should developers build differently? + +External reference: [Digital Markets Act Regulation (EU) 2022/1925](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925). + +Digital Markets Act chapters summary reference: [DMA chapters summary](references/808-regulations-eu-digital-markets-act-chapters-summary.md). + +Java engineering examples reference: [DMA engineering examples](references/808-regulations-eu-digital-markets-act-engineering-examples.md). + +Report template asset: [DMA engineering review report template](assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md). + +## Scope + +This Skill applies to: + +- Java systems that may support a gatekeeper, core platform service, online intermediation service, app store, online search engine, social network, video-sharing platform, number-independent interpersonal communications service, operating system, web browser, virtual assistant, cloud computing service, or online advertising service +- Spring Boot, Quarkus, Micronaut, and framework-agnostic Java services with platform access, interoperability, ranking, self-preferencing, business-user data access, advertising transparency, or consent-dependent data-combination concerns +- APIs, message consumers, batch jobs, exports, reports, ranking pipelines, search indexes, recommendation services, marketplace catalogs, app-store workflows, identity services, payment-service integrations, browser or operating-system defaults, and compliance reporting workflows +- Systems requiring evidence for business-user export workflows, end-user portability, third-party interoperability, advertising metrics, ranking fairness, access terms, consent and preference capture, anti-circumvention controls, and compliance-owner handoff +- Platform changes involving database migrations, Kafka message contracts, feature flags, ranking experiments, access-policy changes, consent UI changes, telemetry schemas, business-user data exports, and production release gates + +## Digital Markets Act Engineering Review + +Treat gatekeeper designation, core platform service scope, obligation applicability, consent interpretation, self-preferencing assessments, fair and reasonable access terms, suspension or exemption requests, and regulatory interpretation as governance decisions for legal, compliance, platform governance, product, privacy, security, risk, competition, and executive accountability owners. + +Engineering teams should still create evidence that makes those decisions reviewable: + +- Which core platform service, business-user journey, end-user journey, data store, API, event stream, ranking system, advertising system, interoperability interface, or platform policy may be in scope +- Which business users, end users, third-party providers, advertisers, publishers, developers, or competitors are affected by the Java system +- Which data access, export, portability, interoperability, consent, preference, ranking, self-preferencing, and anti-circumvention controls exist +- Which logs, metrics, traces, audit events, data lineage records, decision records, release approvals, and compliance reports support review +- Which gaps require owner handoff before production release or continued operation +]]> + + + Translate Digital Markets Act concerns into engineering controls for Java enterprise systems. Do not provide legal advice or replace review by legal, compliance, platform governance, product, privacy, security, risk, competition, or executive accountability owners. + + **NOT LEGAL ADVICE**: Frame findings as gatekeeper-platform engineering controls and escalation points; recommend qualified review for gatekeeper designation, core platform service scope, obligation applicability, consent interpretation, self-preferencing assessments, fair access terms, and regulatory interpretation + **SCOPE FIRST**: Identify possible core platform service, business-user journey, end-user journey, platform owner, data owner, product owner, privacy owner, and compliance owner before recommending controls + **INTEROPERABILITY INTERFACES**: Review technical interfaces, reference offers, security controls, compatibility tests, rate limits, access terms, request workflows, and evidence that interoperability is effective and not degraded + **DATA ACCESS AND EXPORT**: Verify business-user and end-user data access APIs, export workflows, portability tools, advertiser and publisher transparency data, search data access, and consent-dependent personal-data sharing evidence + **CONSENT AND PREFERENCES**: Preserve evidence for specific choice, opt-in, withdrawal, retry limits, neutral UI, preference history, purpose binding, and privacy-owner handoff where personal data is combined, cross-used, or shared + **RANKING AND SELF-PREFERENCING**: Require audit signals for ranking inputs, experiments, business rules, indexing, crawling, sponsored placement, own-service treatment, fairness checks, and non-discriminatory access terms + **ANTI-CIRCUMVENTION**: Do not accept designs that fragment services, degrade quality, hide choices, make rights hard to exercise, or use interface design, technical limits, contractual terms, or data flows to undermine Articles 5, 6, or 7 controls + **ACCESS CONTROL AND OBSERVABILITY**: Verify least privilege, request authentication, authorization, tamper-evident audit logs, metrics, traces, dashboards, alerting, evidence retention, and safe handling of business secrets and personal data + **CHANGE CONTROL**: Treat ranking changes, consent flows, data export schemas, interoperability APIs, access terms, advertising metrics, data lineage, platform defaults, and release gates as DMA evidence events requiring traceable review + + + + + + Review a Java platform for Digital Markets Act controls + Design interoperability interfaces or business-user data access APIs for a core platform service + Add consent, preference, ranking, self-preferencing, advertising transparency, or anti-circumvention audit controls + Assess gatekeeper-platform evidence before production release + Check whether marketplace, app-store, search, advertising, messaging, browser, operating-system, identity, or cloud-platform changes need DMA-aware owner handoff + + + + Read DMA chapters summary, engineering examples, and report templateRead `references/808-regulations-eu-digital-markets-act-chapters-summary.md`, `references/808-regulations-eu-digital-markets-act-engineering-examples.md`, and `assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md` in that order. Use the chapters summary for DMA chapter, article, scope, designation, obligations, interoperability, anti-circumvention, monitoring, enforcement, reporting, and owner-handoff context. Use the engineering examples for Java control patterns such as interoperability interfaces, business-user data access, consent and preference evidence, ranking audit signals, export workflows, anti-circumvention release gates, observability, and compliance evidence handoff. Do not start implementation review until the DMA chapters summary, examples reference, and report template are understood. + Classify the platform scopeIdentify service context, possible core platform service signals, gatekeeper-scope signals, business-user and end-user journeys, platform owners, data owners, product owners, privacy owners, security owners, compliance owners, deployment environments, APIs, data stores, event streams, ranking systems, advertising systems, consent flows, access policies, interoperability interfaces, export workflows, and production release paths. Escalate gatekeeper designation, core platform service classification, obligation applicability, consent interpretation, self-preferencing assessment, fair access terms, suspension or exemption questions, and regulatory interpretation to qualified owners. + Review implementation and compliance evidenceReview Java code, configuration, APIs, DTOs, repositories, schemas, migrations, Kafka messages, ranking code, feature flags, experiments, consent and preference records, audit logs, metrics, traces, dashboards, alerts, export jobs, business-user portals, documentation, tests, release records, and compliance reports. Check for gaps between claimed controls and reviewable evidence. + Recommend engineering controlsMap DMA concerns to engineering actions: interoperability API contracts, reference-offer evidence, data access APIs, export workflows, consent and preference records, ranking and self-preferencing audit signals, advertising transparency metrics, business-user access terms, anti-circumvention guardrails, least privilege, observability, documentation, change approval, and compliance evidence handoff. + Generate review report and owner handoffsUse `assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md` to produce a concise engineering review with scope, evidence reviewed, DMA risk signals, potential violation or non-compliance signals, engineering gaps, recommended controls, owner handoffs, residual risks, release decision, and validation steps. State explicitly that gatekeeper designation, core platform service scope, obligation applicability, consent interpretation, self-preferencing assessments, fair access terms, and regulatory interpretation require qualified owner review. + + diff --git a/skills-generator/src/main/resources/skill-references/808-regulations-eu-digital-markets-act-chapters-summary.xml b/skills-generator/src/main/resources/skill-references/808-regulations-eu-digital-markets-act-chapters-summary.xml new file mode 100644 index 00000000..0d5b3247 --- /dev/null +++ b/skills-generator/src/main/resources/skill-references/808-regulations-eu-digital-markets-act-chapters-summary.xml @@ -0,0 +1,178 @@ + + + + + Juan Antonio Breña Moral + 0.16.0-SNAPSHOT + Apache-2.0 + EU Digital Markets Act Regulation for Java Enterprise Gatekeeper Platform Controls + Use as a chapter-by-chapter and article-by-article summary of Regulation (EU) 2022/1925 to enrich Java enterprise platform reviews with Digital Markets Act context. + + + You are a senior Java enterprise architect and platform compliance reviewer using the Digital Markets Act article structure to map gatekeeper-platform regulatory themes to engineering controls and owner handoffs + + + + + + Use this reference as Digital Markets Act Regulation context for Java engineering review. Do not provide legal advice or replace review by legal, compliance, platform governance, product, privacy, security, risk, competition, executive accountability, or business owners. + + + **NOT LEGAL ADVICE**: State when an article mapping requires legal, compliance, platform governance, product, privacy, security, risk, competition, or executive accountability review instead of giving legal conclusions + **SUMMARY ONLY**: Keep this reference focused on DMA Regulation chapters, articles, annex, and engineering implications; use the engineering examples reference for Java patterns + **ARTICLE MAPPING**: Map findings to DMA topic areas such as gatekeeper designation, core platform service scope, obligations, interoperability, data access, consent, ranking, anti-circumvention, monitoring, enforcement, or final provisions + **OWNER ESCALATION**: Escalate gatekeeper designation, core platform service classification, obligation applicability, consent interpretation, self-preferencing assessments, fair access terms, suspension or exemption requests, and regulatory interpretation to qualified owners + **EVIDENCE ORIENTATION**: Use article summaries to identify what engineering evidence is missing or weak, not to certify compliance + + + + + + **READ** this DMA chapters summary before applying Java examples or generating the review report + **MAP** reviewed findings to DMA topic areas and article groups using only reviewed evidence + **ESCALATE** legal applicability, gatekeeper designation, core platform service scope, obligation applicability, consent interpretation, self-preferencing assessment, fair access terms, and regulatory interpretation to qualified owners + **HAND OFF** implementation control patterns to `808-regulations-eu-digital-markets-act-engineering-examples.md` + + + + + + **DO NOT CERTIFY COMPLIANCE**: This reference supports engineering review and owner handoff only + **CHECK OFFICIAL GUIDANCE**: Implementing acts, guidelines, standardisation, and Commission decisions may add or clarify technical expectations beyond this summary + **KEEP FACTS GROUNDED**: Do not infer gatekeeper designation, core platform service scope, obligation applicability, self-preferencing conclusions, or consent validity without reviewed evidence and qualified owner input + + + diff --git a/skills-generator/src/main/resources/skill-references/808-regulations-eu-digital-markets-act-engineering-examples.xml b/skills-generator/src/main/resources/skill-references/808-regulations-eu-digital-markets-act-engineering-examples.xml new file mode 100644 index 00000000..1780311a --- /dev/null +++ b/skills-generator/src/main/resources/skill-references/808-regulations-eu-digital-markets-act-engineering-examples.xml @@ -0,0 +1,343 @@ + + + + + Juan Antonio Breña Moral + 0.16.0-SNAPSHOT + Apache-2.0 + EU Digital Markets Act Regulation for Java Enterprise Gatekeeper Platform Controls + Use as Java-focused Digital Markets Act engineering examples for interoperability interfaces, business-user data access, consent evidence, ranking audit signals, export workflows, anti-circumvention controls, and compliance evidence handoff. + + + You are a senior Java enterprise architect and platform compliance reviewer who translates Digital Markets Act themes into concrete Java engineering examples and reviewable evidence patterns + + + Apply these DMA-aware examples after the regulation summary has been read and the target platform scope is understood. + + These examples are not legal advice. They show engineering patterns that help Java teams create reviewable evidence for legal, compliance, platform governance, product, privacy, security, risk, competition, and executive accountability owners. + + Use this examples reference together with `808-regulations-eu-digital-markets-act-chapters-summary.md` and the [DMA engineering review report template](../assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md). + + + + + Translate Digital Markets Act concerns into engineering controls for Java enterprise systems without replacing qualified legal, compliance, platform governance, product, privacy, security, risk, competition, or executive accountability review. + + + **NOT LEGAL ADVICE**: Treat the examples as engineering control patterns and escalation aids, not legal findings + **EVIDENCE FIRST**: Prefer reviewable evidence over claims that interoperability, data access, consent, ranking fairness, export, or anti-circumvention controls exist + **OWNER HANDOFFS**: Include platform, product, privacy, security, data, compliance, business-user, and risk owners in control records + **SAFE EVIDENCE**: Preserve DMA evidence without exposing secrets, credentials, personal data, business secrets, confidential ranking logic, or unnecessary platform telemetry + **RELEASE READINESS**: Do not mark a system ready when critical DMA controls are undocumented, untested, ownerless, inaccessible to business users, or dependent on unclear compliance interpretation + + + + + + + + + Design interoperability interfaces with reviewable safeguards + API contracts, reference offer evidence, compatibility, security, and request handling + + + + + + + + + + + + + + + + + Expose business-user data access with consent and lineage + continuous access, export jobs, personal-data boundaries, and audit evidence + + + + + + + + + + + + + + + + + Preserve consent and preference evidence before combining data + specific choice, withdrawal, retry limits, purpose binding, and neutral UI + + + + + + + + + + + + + + + + + Audit ranking and self-preferencing signals + ranking inputs, own-service flags, experiments, sponsored placement, and fairness checks + + + + + + + + + + + + + + + + + Make business-user exports operable and observable + request lifecycle, format, errors, delivery, retention, and support handoff + + + + + + + + + + + + + + + + + Block releases that undermine DMA controls + neutral choices, no degradation, service-boundary integrity, and evidence handoff + + + + + + + blockers = new ArrayList<>(); + + requirePresent(review.corePlatformServiceScope(), "core platform service scope evidence", blockers); + requirePassing(review.interoperabilityContractTests(), "interoperability contract tests", blockers); + requirePresent(review.dataAccessApiEvidence(), "business-user data access evidence", blockers); + requirePassing(review.consentPreferenceAudit(), "consent and preference audit evidence", blockers); + requirePassing(review.rankingFairnessReview(), "ranking and self-preferencing review", blockers); + requirePresent(review.exportWorkflowRunbook(), "business-user export workflow", blockers); + requirePassing(review.neutralChoiceReview(), "neutral choice and no-degradation review", blockers); + requirePresent(review.complianceHandoff(), "qualified owner handoff", blockers); + + if (!blockers.isEmpty()) { + return ReleaseDecision.blocked( + review.serviceId(), + blockers, + Escalation.required("legal", "compliance", "platform-governance", "product", "privacy", "security", "risk") + ); + } + + return ReleaseDecision.approvedWithEvidence( + review.serviceId(), + review.evidenceReferences(), + review.approvers() + ); +}]]> + + + + + + + + + + + **MATCH** the relevant example patterns: interoperability interface evidence, business-user data access API, consent and preference evidence, ranking audit signals, business-user export workflow, or anti-circumvention release gate + **RECOMMEND** engineering controls: interoperability APIs, reference offers, compatibility tests, data access APIs, export workflows, consent records, neutral preference UX, ranking audit events, self-preferencing review, advertiser or publisher metrics, access control, observability, evidence retention, documentation, change approval, and compliance handoff + **REPORT** conclusions and actions using `../assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md`, including review context, platform scope, evidence reviewed, DMA risk signals, potential violation or non-compliance signals with owner handoff, engineering controls, residual risks, release decision, and prioritized action plan with owners and due dates + + + + + + **DMA EVIDENCE**: Do not accept undocumented claims that interoperability, business-user access, consent, ranking fairness, export, advertising transparency, or anti-circumvention controls exist; ask for reviewable evidence + **PLATFORM RELIANCE**: Apply stronger controls when a Java system affects marketplaces, app stores, search, advertising, messaging, identity, browser or operating-system defaults, cloud platforms, or business-user platform access + **OWNER ESCALATION**: Route gatekeeper designation, core platform service classification, obligation applicability, consent interpretation, self-preferencing conclusions, fair access terms, and regulatory interpretation to qualified owners + + + diff --git a/skills-generator/src/main/resources/skill-references/assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md b/skills-generator/src/main/resources/skill-references/assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md new file mode 100644 index 00000000..1d82f80f --- /dev/null +++ b/skills-generator/src/main/resources/skill-references/assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md @@ -0,0 +1,140 @@ +# EU Digital Markets Act Engineering Review Report + +Use this template after reviewing `../../references/808-regulations-eu-digital-markets-act-chapters-summary.md` and matching the relevant examples from `../../references/808-regulations-eu-digital-markets-act-engineering-examples.md` for interoperability interfaces, business-user data access, consent and preference evidence, ranking audit signals, business-user export workflows, anti-circumvention controls, and compliance evidence handoff. + +This report is not legal advice. Use it as engineering evidence for legal, compliance, platform governance, product, privacy, security, risk, competition, executive accountability, architecture, and business-owner review. + +The purpose of this report is to increase awareness of potential gaps in the system and create engineering evidence for qualified review. The response produced from this template does not represent legal advice, a legal opinion, a gatekeeper designation, a core platform service classification, or a final regulatory determination. + +## 1. Review Context + +- System or service name: +- Repository, product, platform, or business service: +- Review date: +- Reviewers: +- Business owner: +- Technical owner: +- Platform owner: +- Product owner: +- Data owner: +- Privacy owner: +- Security owner: +- Legal/compliance owner: +- Source materials reviewed: + +## 2. Platform And Core Service Context + +- Service description: +- Possible core platform service signal: +- Possible gatekeeper-scope signal: +- Business-user journey: +- End-user journey: +- Deployment geography: +- Environments in scope: +- Platform dependencies: +- Open applicability questions: + +## 3. DMA Engineering Scope + +- Applications, APIs, jobs, and batch workloads: +- Data stores, queues, topics, indexes, and caches: +- Business-user data access APIs: +- End-user portability or preference workflows: +- Interoperability interfaces: +- Ranking, search, recommendation, or advertising systems: +- Consent, preference, and identity flows: +- Marketplace, app-store, browser, operating-system, messaging, cloud, or advertising features: +- IAM, secrets, keys, and privileged operations: +- CI/CD workflows and deployment paths: +- Monitoring, alerting, and observability systems: +- Documentation, compliance reports, and owner handoff records: + +## 4. Potential Violation Or Non-Compliance Mapping + +This section is not a legal finding. Use it to list concrete potential Digital Markets Act violation or non-compliance signals from the reviewed evidence and route each item to qualified legal, compliance, platform governance, product, privacy, security, risk, competition, or executive accountability review. When no violation is confirmed, say so explicitly and keep open items as potential gaps. Use the official-source links from `../../references/808-regulations-eu-digital-markets-act-chapters-summary.md`; add more links when one finding spans multiple DMA areas. + +| Potential violation or non-compliance signal | DMA reference area | Associated official-source link | Evidence from reviewed system | Current status | Required owner review | Engineering action | +| -------------------------------------------- | ------------------ | ------------------------------- | ----------------------------- | -------------- | --------------------- | ------------------ | +| Unclear gatekeeper or core platform service scope | Applicability / designation / service listing | [Chapter I](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_I), [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_II), [Annex](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#anx) | TBD | None identified / Potential gap / Confirmed concern | Legal / compliance / platform governance / product | TBD | +| Missing or weak interoperability evidence | Interoperability / effective access / security preservation | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | TBD | None identified / Potential gap / Confirmed concern | Platform / security / compliance | TBD | +| Missing business-user data access or export workflow evidence | Business-user data access / data portability / advertiser or publisher transparency | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | TBD | None identified / Potential gap / Confirmed concern | Product / data owner / compliance / privacy | TBD | +| Missing consent and preference evidence for data combination or sharing | Consent / personal-data combination / preference handling | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | TBD | None identified / Potential gap / Confirmed concern | Privacy / legal / product | TBD | +| Missing ranking or self-preferencing audit signals | Ranking / fair and non-discriminatory treatment / own-service treatment | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | TBD | None identified / Potential gap / Confirmed concern | Product / competition / compliance / architecture | TBD | +| Anti-circumvention or degraded-choice risk | Anti-circumvention / non-neutral choice / degraded quality / service fragmentation | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III) | TBD | None identified / Potential gap / Confirmed concern | Legal / compliance / platform governance / product | TBD | +| Incomplete compliance reporting, monitoring, or evidence handoff | Compliance demonstration / reporting / monitoring / enforcement | [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_III), [Chapter V](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R1925#cpt_V) | TBD | None identified / Potential gap / Confirmed concern | Compliance / security / risk / executive accountability | TBD | + +## 5. Engineering Controls + +- Interoperability interfaces: +- Data access APIs: +- Business-user export workflows: +- End-user portability workflows: +- Consent and preference evidence: +- Ranking and self-preferencing audit signals: +- Advertising transparency metrics: +- Fair and non-discriminatory access terms: +- Anti-circumvention guardrails: +- Access control and least privilege: +- Evidence-safe logging: +- Monitoring, metrics, traces, and alerting: +- Documentation and runbooks: +- Change control and release gates: +- Compliance evidence handoff: + +## 6. Evidence Inventory + +- Core platform service inventory: +- Business-user and end-user journey map: +- Active-user metric methodology: +- Interoperability interface contract: +- Data access API contract: +- Export workflow runbook: +- Consent and preference records: +- Ranking audit events: +- Advertising or search data evidence: +- Access-control policy: +- Monitoring dashboards: +- Alert routing: +- Compliance report or summary: +- Change approval: +- Release decision: + +## 7. Residual Risks + +- Residual risk: +- Impact: +- Likelihood: +- Mitigation: +- Owner: +- Acceptance decision: +- Review date: + +## 8. Release Decision + +- Decision: +- Conditions: +- Blockers: +- Required approvals: +- Expiry or review date: +- Environments approved: +- Emergency rollback path: + +## 9. Action Plan + +| Priority | Action | Owner | Due date | Evidence expected | Status | +| -------- | ------ | ----- | -------- | ----------------- | ------ | +| High | | | | | Open | +| Medium | | | | | Open | +| Low | | | | | Open | + +## 10. Final Notes + +- Items requiring legal interpretation: +- Items requiring platform governance decision: +- Items requiring product decision: +- Items requiring privacy or consent review: +- Items requiring security exception: +- Items requiring architecture decision: +- Items requiring competition or compliance review: +- Items requiring business acceptance: +- Next review trigger: diff --git a/skills-generator/src/main/resources/skills.xml b/skills-generator/src/main/resources/skills.xml index c45bd266..a51e7474 100644 --- a/skills-generator/src/main/resources/skills.xml +++ b/skills-generator/src/main/resources/skills.xml @@ -610,6 +610,16 @@ target="assets/reports/805-eu-cyber-resilience-act-engineering-review-report-template.md" /> + + + 808-regulations-eu-digital-markets-act-chapters-summary + 808-regulations-eu-digital-markets-act-engineering-examples + + + + + 809-regulations-eu-digital-omnibus-source-summary diff --git a/skills-generator/src/test/resources/gherkin/808-regulations-eu-digital-markets-act.feature b/skills-generator/src/test/resources/gherkin/808-regulations-eu-digital-markets-act.feature new file mode 100644 index 00000000..9e6f8374 --- /dev/null +++ b/skills-generator/src/test/resources/gherkin/808-regulations-eu-digital-markets-act.feature @@ -0,0 +1,64 @@ +Feature: Validate changes from usage of EU Digital Markets Act regulation skill + +Background: + Given the skill "808-regulations-eu-digital-markets-act" + +@acceptance-test +Scenario: Review a Java platform change with EU Digital Markets Act controls + Given the system description file "examples/diagrams/deployment/system-example-cicd-pr-model.md" + And the deployment and delivery pipeline diagram file "examples/diagrams/deployment/expected-system-deployment.puml" + And the simulated feature request file "examples/diagrams/deployment/checkout-service-feature-request.md" + And the local generated skill path ".agents/skills/808-regulations-eu-digital-markets-act" + And the requested report output path is "examples/regulations/eu-digital-markets-act/DMA-ENGINEERING-REVIEW-REPORT.md" + And any existing report at the requested output path must be overwritten + And the folder "examples/regulations/eu-digital-markets-act" has no git changes + And the feature request is expected to be developed and released through the described CI/CD pipeline + And the DMA review facts are based only on information present in "examples/diagrams/deployment/system-example-cicd-pr-model.md" and "examples/diagrams/deployment/checkout-service-feature-request.md" + When the skill ".agents/skills/808-regulations-eu-digital-markets-act" is applied to the system description, diagram, and feature request files + Then the skill reads "references/808-regulations-eu-digital-markets-act-chapters-summary.md" + And the skill reads "references/808-regulations-eu-digital-markets-act-engineering-examples.md" + And the skill reads "assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md" + And the skill frames Digital Markets Act findings as engineering controls rather than legal advice + And review findings do not use facts outside "examples/diagrams/deployment/system-example-cicd-pr-model.md" and "examples/diagrams/deployment/checkout-service-feature-request.md" + And the skill scopes possible core platform service signals, gatekeeper-scope signals, business-user journeys, end-user journeys, system owners, platform owners, product owners, privacy owners, security owners, compliance owners, environments, APIs, data stores, event streams, ranking systems, advertising systems, consent flows, access policies, interoperability interfaces, export workflows, and release paths + And the skill escalates gatekeeper designation, core platform service scope, obligation applicability, consent interpretation, self-preferencing assessments, fair access terms, suspension or exemption questions, and regulatory interpretation to legal, compliance, platform governance, product, privacy, security, risk, competition, or executive accountability owners + And the skill reviews Java implementation, configuration, APIs, DTOs, repositories, schemas, migrations, messages, ranking logic, feature flags, experiments, consent and preference records, audit logs, metrics, traces, dashboards, alerts, export jobs, business-user portals, documentation, tests, release records, and compliance reports + And the skill identifies risk signals for unclear core platform service scope, missing interoperability evidence, missing business-user data access APIs, missing consent and preference evidence, missing ranking and self-preferencing audit signals, missing business-user export workflows, weak anti-circumvention guardrails, weak access control, incomplete observability, weak change control, incomplete documentation, database migration, Kafka message contract, CI/CD pipeline, and production side-effect signals + And the skill maps potential DMA violation or non-compliance signals to article or chapter references with associated official-source links using only the reviewed delivery evidence + And the skill analyzes the CheckoutService feature request as a pipeline-delivered platform change that modifies order database structure and outbound Kafka event data + And the skill uses Java examples to explain interoperability interfaces, business-user data access, consent and preference evidence, ranking audit signals, business-user export workflows, anti-circumvention release gates, and compliance evidence handoff + And the skill recommends engineering controls for interoperability interfaces, data access APIs, consent and preference evidence, ranking and self-preferencing audit signals, business-user export workflows, anti-circumvention guardrails, access control, observability, change control, documentation, database migration approval, Kafka schema compatibility, and compliance evidence handoff + And the skill reports conclusions and actions using the EU Digital Markets Act engineering review report template + And the generated report contains a potential violation or non-compliance mapping table with associated official-source links + And the skill overwrites the EU Digital Markets Act engineering review report at "examples/regulations/eu-digital-markets-act/DMA-ENGINEERING-REVIEW-REPORT.md" + And any git changes produced during skill execution and verification are reset + +@acceptance-test +Scenario: Review a Java platform change with direct-to-main EU Digital Markets Act controls + Given the system description file "examples/diagrams/deployment/system-example-cicd-model.md" + And the deployment and delivery pipeline diagram file "examples/diagrams/deployment/expected-system-deployment.puml" + And the simulated feature request file "examples/diagrams/deployment/checkout-service-feature-request.md" + And the local generated skill path ".agents/skills/808-regulations-eu-digital-markets-act" + And the requested report output path is "examples/regulations/eu-digital-markets-act/DMA-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md" + And any existing report at the requested output path must be overwritten + And the folder "examples/regulations/eu-digital-markets-act" has no git changes + And the feature request is expected to be committed directly to main and released through the described CI/CD pipeline + And the DMA review facts are based only on information present in "examples/diagrams/deployment/system-example-cicd-model.md" and "examples/diagrams/deployment/checkout-service-feature-request.md" + When the skill ".agents/skills/808-regulations-eu-digital-markets-act" is applied to the direct-to-main system description, diagram, and feature request files + Then the skill reads "references/808-regulations-eu-digital-markets-act-chapters-summary.md" + And the skill reads "references/808-regulations-eu-digital-markets-act-engineering-examples.md" + And the skill reads "assets/reports/808-eu-digital-markets-act-engineering-review-report-template.md" + And the skill frames Digital Markets Act findings as engineering controls rather than legal advice + And review findings do not use facts outside "examples/diagrams/deployment/system-example-cicd-model.md" and "examples/diagrams/deployment/checkout-service-feature-request.md" + And the skill scopes possible core platform service signals, gatekeeper-scope signals, business-user journeys, end-user journeys, system owners, platform owners, product owners, privacy owners, security owners, compliance owners, environments, APIs, data stores, event streams, ranking systems, advertising systems, consent flows, access policies, interoperability interfaces, export workflows, and release paths + And the skill escalates missing pre-merge review, protected-main bypass, gatekeeper designation, core platform service scope, obligation applicability, consent interpretation, self-preferencing assessments, fair access terms, suspension or exemption questions, and regulatory interpretation to legal, compliance, platform governance, product, privacy, security, platform, risk, competition, or executive accountability owners + And the skill reviews Java implementation, configuration, APIs, DTOs, repositories, schemas, migrations, messages, ranking logic, feature flags, experiments, consent and preference records, audit logs, metrics, traces, dashboards, alerts, export jobs, business-user portals, documentation, tests, release records, and compliance reports + And the skill identifies risk signals for unclear core platform service scope, missing interoperability evidence, missing business-user data access APIs, missing consent and preference evidence, missing ranking and self-preferencing audit signals, missing business-user export workflows, weak anti-circumvention guardrails, weak access control, incomplete observability, weak change control, incomplete documentation, direct-to-main commit policy, database migration, Kafka message contract, CI/CD pipeline, and production side-effect signals + And the skill maps potential DMA violation or non-compliance signals to article or chapter references with associated official-source links using only the reviewed direct-to-main delivery evidence + And the skill analyzes the CheckoutService feature request as a direct-to-main platform change that modifies order database structure and outbound Kafka event data + And the skill uses Java examples to explain interoperability interfaces, business-user data access, consent and preference evidence, ranking audit signals, business-user export workflows, anti-circumvention release gates, and compliance evidence handoff + And the skill recommends engineering controls for pre-commit review, main-branch protection, interoperability interfaces, data access APIs, consent and preference evidence, ranking and self-preferencing audit signals, business-user export workflows, anti-circumvention guardrails, access control, observability, change control, documentation, database migration approval, Kafka schema compatibility, and compliance evidence handoff + And the skill reports conclusions and actions using the EU Digital Markets Act engineering review report template + And the generated report contains a potential violation or non-compliance mapping table with associated official-source links + And the skill overwrites the EU Digital Markets Act engineering review report at "examples/regulations/eu-digital-markets-act/DMA-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md" + And any git changes produced during skill execution and verification are reset diff --git a/skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md b/skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md index 352a9217..429af1a7 100644 --- a/skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md +++ b/skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md @@ -76,6 +76,7 @@ and verify that acceptance-tests passes. execute @skills-generator/src/test/resources/gherkin/805-regulations-eu-cyber-resilience-act.feature and verify that acceptance-tests passes. ``` + ## 807-regulations-eu-digital-services-act ```bash @@ -83,10 +84,16 @@ execute @skills-generator/src/test/resources/gherkin/807-regulations-eu-digital- and verify that acceptance-tests passes. ``` +## 808-regulations-eu-digital-markets-act + +```bash +execute @skills-generator/src/test/resources/gherkin/808-regulations-eu-digital-markets-act.feature +and verify that acceptance-tests passes. +``` + ## 809-regulations-eu-digital-omnibus ```bash execute @skills-generator/src/test/resources/gherkin/809-regulations-eu-digital-omnibus.feature and verify that acceptance-tests passes. ``` -