Skip to content

Dynamically materialize TheHive case-management service as a composable kit chunk #1091

Description

@Brad-Edwards

Goal

Make infrastructure.thehive-case-management-service@1.0.0 a fully dynamically composable APTL materialization chunk. When an admitted environment pack uses this kit, APTL must consume the released kit materialization and expanded RAES SDL as authority, then actually create and verify the declarations exported by this module.

This is one kit-sized slice of milestone #36. It is not complete when a generic placeholder container starts or when APTL merely recognizes the kit identifier.

Declared chunk surface

  • Concern: security-operations
  • Parameters: deployment_profile, service_label, organization_name
  • Exported RAES declarations: accounts.case_analyst; content.seed_inventory; nodes.case_manager, nodes.storage
  • Published kit assets remain operator-visible; their admitted artifact identity must be preserved and disclosed.

Acceptance criteria

  • APTL admits this exact released kit through the shared env-packs contract, preserving the source revision, lock/materialization provenance, associated-artifact identity, namespace, and selected parameter values. No copied kit manifest or APTL-private kit schema is introduced.
  • The expanded RAES SDL is the realization authority. APTL plans and dynamically realizes every exported declaration listed above, including all nodes and their declared source, resource, service, application-route, and realization-constraint surfaces where present.
  • Declared accounts, seeded content, identities, and intra-kit relationships are made real through backend-owned mechanisms where their RAES declaration requires it; the proof identifies the resulting surface without exposing credentials or protected material.
  • Every unresolved RAES source reference selected by this kit is resolved to an actual admitted runtime artifact at realization time, or the run fails closed with a precise diagnostic. A placeholder or unverified substitute cannot count as success.
  • A per-component proof record links the kit identity/version, pack artifact identity, namespace and parameters, each exported declaration pointer, the selected runtime artifact, and observed readiness/functional evidence appropriate to that declaration.
  • A focused fixture composes this kit into an ordinary pack and proves the full chunk from admission through materialization. It exercises a non-default meaningful parameter and fails if any exported declaration is absent, unverified, or silently replaced.
  • The kit can coexist with another independently materialized kit through ordinary pack-root RAES relationships. This issue does not invent undeclared product integration semantics between the two kits.
  • Update, replacement, and removal preserve ownership and evidence boundaries; unsupported changes fail explicitly rather than mutating unrelated author-owned SDL or resources.

Boundary

OpenRAE/env-packs owns the released kit, its layout, assets, and authoring contract. RAES owns the declaration semantics. APTL owns artifact selection, provisioning, lifecycle, credentials, readiness checks, teardown, and evidence. Do not extend RAES semantics or claim runtime behavior that the observed proof does not establish.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    aces-scenario-packsACES scenario-pack companion repositorycross-repoCoordinates or depends on delivery in another repositoryenhancementNew feature or requestscope:aptl-backend-capabilityGeneric backend capability to realize scenario-declared tools/services.

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions