docs: document 10+ undocumented module types#102
Conversation
#95) Verified that all JWT validation paths in JWTAuthModule already enforce HS256 via both type assertion (*jwt.SigningMethodHMAC) and explicit algorithm check (token.Method.Alg() != jwt.SigningMethodHS256.Alg()). Added tests to module/jwt_auth_test.go that explicitly confirm tokens signed with HS384 or HS512 are rejected by: - Authenticate() — the AuthProvider interface method - handleRefresh via Handle() — the /auth/refresh endpoint - extractUserFromRequest via Handle() — all protected endpoints The api package (middleware.go, auth_handler.go) already had equivalent algorithm rejection tests in auth_handler_test.go. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
#66) Adds detailed documentation for audit logging, license.validator, platform.provider/resource/context, observability.otel, step.jq, AI pipeline steps (ai_complete, ai_classify, ai_extract), CI/CD steps (docker_build, docker_push, docker_run, scan_sast, scan_container, scan_deps, artifact_push, artifact_pull), and the admincore plugin. Each entry includes config field tables with types and defaults, plus a minimal YAML example. Summary tables in the module type index are also updated with the new Infrastructure and CI/CD Step categories. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR adds comprehensive documentation for 10+ previously undocumented module types to DOCUMENTATION.md, addressing issue #66. The documentation follows the established pattern with configuration tables, descriptions, and YAML examples for each module type.
Changes:
- Adds summary table entries for new Infrastructure (license.validator, platform.*) and CI/CD Pipeline Steps (Docker, scanning, artifact management) categories
- Creates a new "Module Type Reference" section with detailed documentation for 19 module types/features
- Includes unrelated JWT security tests that add algorithm confusion attack prevention validation
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
| DOCUMENTATION.md | Adds Module Type Reference section documenting audit logging, license validator, platform modules (provider/resource/context), observability.otel, AI steps (jq, ai_complete, ai_classify, ai_extract), Docker/CI steps (build, push, run, SAST/container/deps scanning, artifact push/pull), and admincore plugin |
| module/jwt_auth_test.go | Adds 120+ lines of JWT algorithm confusion attack prevention tests (TestJWTAuth_Authenticate_RejectsNonHS256, TestJWTAuth_HandleRefresh_RejectsNonHS256, TestJWTAuth_ExtractUser_RejectsNonHS256) that verify HS256 enforcement |
| ### `platform.context` | ||
|
|
||
| Provides the execution context for platform operations. Used to identify the organization, environment, and tier for a deployment. | ||
|
|
||
| **Configuration:** | ||
|
|
||
| | Key | Type | Required | Description | | ||
| |-----|------|----------|-------------| | ||
| | `path` | string | yes | Path identifying this context. | | ||
| | `org` | string | no | Organization name. | | ||
| | `environment` | string | no | Deployment environment (e.g., `production`, `staging`). | | ||
| | `tier` | number | no | Platform tier level. | | ||
|
|
||
| **Example:** | ||
|
|
||
| ```yaml | ||
| modules: | ||
| - name: platform-ctx | ||
| type: platform.context | ||
| config: | ||
| path: "acme-corp/production" | ||
| org: "acme-corp" | ||
| environment: "production" | ||
| tier: 3 | ||
| ``` |
There was a problem hiding this comment.
The documentation shows a path config field for platform.context that does not exist in the schema definition (schema/module_schema.go:1426-1430). The schema only defines org, environment, and tier fields. Additionally, the example shows tier as a number (3), but the schema defines it as a string select field with options "infrastructure", "shared_primitive", or "application". Remove the path field and correct the tier type and example value.
| ### `observability.otel` | ||
|
|
||
| Initializes an OpenTelemetry distributed tracing provider that exports spans via OTLP/HTTP to a collector. Sets the global OTel tracer provider so all instrumented code in the process is covered. | ||
|
|
||
| **Configuration:** | ||
|
|
||
| | Key | Type | Default | Description | | ||
| |-----|------|---------|-------------| | ||
| | `endpoint` | string | `localhost:4318` | OTLP collector endpoint (host:port). | | ||
| | `serviceName` | string | `workflow` | Service name used for trace attribution. | | ||
|
|
||
| **Outputs:** Provides the `tracer` service (`trace.Tracer`). | ||
|
|
||
| **Example:** | ||
|
|
||
| ```yaml | ||
| modules: | ||
| - name: tracing | ||
| type: observability.otel | ||
| config: | ||
| endpoint: "otel-collector:4318" | ||
| serviceName: "order-api" | ||
| ``` |
There was a problem hiding this comment.
The observability.otel module factory does not read the endpoint and serviceName configuration fields from the YAML config. The factory implementation in plugins/observability/modules.go line 85 ignores the config parameter. Either the factory needs to be updated to read these fields and call SetEndpoint() and SetServiceName() on the module, or the documentation should clarify that these config fields are not currently implemented and the module uses hardcoded defaults.
| ### `platform.provider` | ||
|
|
||
| Declares a cloud infrastructure provider (e.g., Terraform, Pulumi) for use with the platform workflow handler and reconciliation trigger. | ||
|
|
||
| **Configuration:** | ||
|
|
||
| | Key | Type | Required | Description | | ||
| |-----|------|----------|-------------| | ||
| | `name` | string | yes | Provider name used to construct the service name `platform.provider.<name>`. | | ||
|
|
||
| **Example:** | ||
|
|
||
| ```yaml | ||
| modules: | ||
| - name: cloud-provider | ||
| type: platform.provider | ||
| config: | ||
| name: "aws" | ||
| ``` | ||
|
|
There was a problem hiding this comment.
The platform.provider documentation is incomplete compared to the schema definition in schema/module_schema.go:1390-1401. The schema shows three config fields (name, config, and tiers), but this documentation only mentions name. The documented description also differs from the schema. Consider either documenting all three config fields or explaining that some are not yet implemented.
| ### `platform.resource` | ||
|
|
||
| Declares an infrastructure resource managed by a platform provider. Config keys are provider-specific and passed through as-is. | ||
|
|
||
| **Configuration:** | ||
|
|
||
| | Key | Type | Required | Description | | ||
| |-----|------|----------|-------------| | ||
| | `type` | string | yes | Infrastructure resource type (e.g., `database`, `queue`, `container_runtime`). | | ||
| | *(additional keys)* | any | no | Provider-specific resource properties. | | ||
|
|
||
| **Example:** | ||
|
|
||
| ```yaml | ||
| modules: | ||
| - name: orders-db | ||
| type: platform.resource | ||
| config: | ||
| type: database | ||
| engine: postgresql | ||
| storage: "10Gi" | ||
| ``` | ||
|
|
There was a problem hiding this comment.
The platform.resource documentation is incomplete compared to the schema definition in schema/module_schema.go:1403-1418. The schema shows five config fields (name, type, tier, capabilities, and constraints), but this documentation only shows type. The documented description differs significantly from the schema, which describes it as "A capability-based resource declaration managed by the platform abstraction layer" with additional fields for tier, capabilities, and constraints.
| ### `platform.context` | ||
|
|
||
| Provides the execution context for platform operations. Used to identify the organization, environment, and tier for a deployment. | ||
|
|
||
| **Configuration:** | ||
|
|
||
| | Key | Type | Required | Description | | ||
| |-----|------|----------|-------------| | ||
| | `path` | string | yes | Path identifying this context. | | ||
| | `org` | string | no | Organization name. | | ||
| | `environment` | string | no | Deployment environment (e.g., `production`, `staging`). | | ||
| | `tier` | number | no | Platform tier level. | | ||
|
|
||
| **Example:** | ||
|
|
||
| ```yaml | ||
| modules: | ||
| - name: platform-ctx | ||
| type: platform.context | ||
| config: | ||
| path: "acme-corp/production" | ||
| org: "acme-corp" | ||
| environment: "production" | ||
| tier: 3 | ||
| ``` |
There was a problem hiding this comment.
The platform.context documentation is incomplete compared to the schema definition in schema/module_schema.go:1420-1433. The schema shows three required config fields (org, environment, and tier), but this documentation marks org, environment, and tier as not required. The schema shows all three fields are required except tier which has a default. The documentation should match the schema's required field designation.
|
@copilot open a new pull request to apply changes based on the comments in this thread |
…rm.*, and observability.otel modules (#109) * Initial plan * fix: correct documentation inaccuracies for license.validator, platform.*, and observability.otel modules Co-authored-by: intel352 <77607+intel352@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: intel352 <77607+intel352@users.noreply.github.com>
Resolve DOCUMENTATION.md conflicts by keeping the PR branch version, which matches the canonical schema definitions in schema/module_schema.go: - license_key: env var fallback, not $ENV_VAR expansion (matches source) - platform.provider: 3 config fields (name, config, tiers) per schema - platform.resource: 5 config fields (name, type, tier, capabilities, constraints) - platform.context: org/environment/tier as strings, not path/number Also remove duplicate requestsPerHour/requestsPerMinute parsing block in plugins/http/modules.go that caused a typecheck lint failure. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| func otelTracingFactory(name string, cfg map[string]any) modular.Module { | ||
| m := module.NewOTelTracing(name) | ||
| if v, ok := cfg["endpoint"].(string); ok && v != "" { | ||
| m.SetEndpoint(v) | ||
| } | ||
| if v, ok := cfg["serviceName"].(string); ok && v != "" { | ||
| m.SetServiceName(v) | ||
| } |
There was a problem hiding this comment.
otelTracingFactory now reads cfg["endpoint"]/cfg["serviceName"] without guarding against cfg == nil. Since module config: is optional (and observability.otel has no required config fields), a YAML module that omits config will pass a nil map and this will panic. Add a nil check (or normalize nil to an empty map) before indexing into cfg.
Prevents potential issues when a module omits the config: section in YAML, which passes a nil map to the factory function. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Addressing review feedbackAll 8 review comments have been addressed: Already fixed in merge conflict resolution (f58eb92)
Not applicable
Already fixed by this PR branch
Fixed in latest push (bf99a09)
|
Summary
audit/package,license.validator,platform.provider,platform.resource,platform.context,observability.otel,step.jq,step.ai_complete,step.ai_classify,step.ai_extract,step.docker_build,step.docker_push,step.docker_run,step.scan_sast,step.scan_container,step.scan_deps,step.artifact_push,step.artifact_pull, and theadmincorepluginCloses #66
Test plan
module/,audit/, andplugins/go build ./...golangci-lint run🤖 Generated with Claude Code