-
Notifications
You must be signed in to change notification settings - Fork 0
Add demo validation CI workflow and expand demo/readiness docs #96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,95 @@ | ||
| name: Demo Validation | ||
|
|
||
| on: | ||
| pull_request: | ||
| paths: | ||
| - 'src/app/demo/**' | ||
| - 'src/app/api/demo/**' | ||
| - 'src/lib/demo/**' | ||
| - 'scripts/capture-demo-media.ts' | ||
| - 'tests/api/demo-session-start.test.ts' | ||
| - 'docs/DEMO_MEDIA_CAPTURE.md' | ||
| - 'docs/DEMO_READINESS_CHECKLIST.md' | ||
| - 'package.json' | ||
| - 'package-lock.json' | ||
| - '.github/workflows/demo-validation.yml' | ||
| push: | ||
| branches: [main] | ||
| paths: | ||
| - 'src/app/demo/**' | ||
| - 'src/app/api/demo/**' | ||
| - 'src/lib/demo/**' | ||
| - 'scripts/capture-demo-media.ts' | ||
| - 'tests/api/demo-session-start.test.ts' | ||
| - 'docs/DEMO_MEDIA_CAPTURE.md' | ||
| - 'docs/DEMO_READINESS_CHECKLIST.md' | ||
| - 'package.json' | ||
| - 'package-lock.json' | ||
| - '.github/workflows/demo-validation.yml' | ||
|
|
||
| permissions: | ||
| contents: read | ||
|
|
||
| concurrency: | ||
| group: demo-validation-${{ github.workflow }}-${{ github.ref }} | ||
| cancel-in-progress: true | ||
|
|
||
| jobs: | ||
| validate-demo: | ||
| name: Validate browser demo and media capture | ||
| runs-on: ubuntu-latest | ||
| timeout-minutes: 25 | ||
|
|
||
| env: | ||
| CI: 'true' | ||
| NEXT_TELEMETRY_DISABLED: '1' | ||
| # Keep capture deterministic and local-only. The media script starts a local dev server if needed. | ||
| DEMO_MEDIA_SERVER_COMMAND: npm run dev | ||
| DEMO_MEDIA_SERVER_TIMEOUT_MS: '90000' | ||
|
|
||
| steps: | ||
| - name: Checkout code | ||
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Setup Node.js | ||
| uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: '22' | ||
| cache: npm | ||
|
|
||
| - name: Setup Bun for demo media script | ||
| uses: oven-sh/setup-bun@v2 | ||
| with: | ||
| bun-version: latest | ||
|
|
||
| - name: Install dependencies | ||
| run: npm ci | ||
|
|
||
| - name: TypeScript type check | ||
| run: npm run typecheck | ||
|
|
||
| - name: ESLint | ||
| run: npm run lint | ||
|
|
||
| - name: Build | ||
| run: npm run build | ||
|
|
||
| - name: Run demo API unit test | ||
| run: npx vitest run tests/api/demo-session-start.test.ts | ||
|
|
||
| - name: Generate deterministic demo media | ||
| run: npm run demo:media | ||
| env: | ||
| DEMO_MEDIA_BASE_URL: http://localhost:3000 | ||
|
|
||
| - name: Verify demo media report exists | ||
| run: test -f artifacts/demo-media/capture-report.json | ||
|
|
||
| - name: Upload demo media artifacts | ||
| if: always() | ||
| uses: actions/upload-artifact@v4 | ||
| with: | ||
| name: demo-media-${{ github.run_id }} | ||
| path: artifacts/demo-media/ | ||
| if-no-files-found: error | ||
| retention-days: 14 | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,57 @@ | ||
| # Architecture Future Notes | ||
| # SignalGrid Architecture Future Notes | ||
|
|
||
| (Your content here) | ||
| These notes describe future architecture direction. They are not current production claims. | ||
|
|
||
| ## Event-driven decision gateway direction | ||
|
|
||
| SignalGrid should evolve toward an event-driven decision gateway that: | ||
|
|
||
| - Receives signed events from badge, identity, posture, location, and session sources. | ||
| - Normalizes context into a consistent policy input. | ||
| - Produces explicit decisions such as allow, deny, step-up, quarantine request, or ticket request. | ||
| - Emits auditable decision records and downstream integration events. | ||
| - Keeps customer-specific integrations behind well-defined adapters. | ||
|
|
||
| The gateway should remain deterministic and explainable for high-consequence frontline workflows. | ||
|
|
||
| ## Constrained remediation playbooks | ||
|
|
||
| Future remediation should be modeled as bounded playbooks, not open-ended automation. A safe playbook should include: | ||
|
|
||
| - Trigger conditions and required input fields. | ||
| - Allowed actions and disallowed actions. | ||
| - Approval requirements for high-risk steps. | ||
| - Timeout, retry, and rollback behavior. | ||
| - Re-check criteria before access is allowed. | ||
| - Audit records for `attempted`, `succeeded`, `failed`, and `final decision` states. | ||
|
|
||
| ## AI-assisted explanation/classification | ||
|
|
||
| AI-assisted capabilities may be useful later for summarizing decision context, classifying event patterns, or drafting operator-facing explanations. These should remain future-only until guardrails are implemented. | ||
|
|
||
| Any AI-assisted workflow must: | ||
|
|
||
| - Avoid autonomous high-risk enforcement. | ||
| - Use structured inputs and bounded outputs. | ||
| - Preserve policy-engine authority for final decisions. | ||
| - Cite the signals and rules behind generated explanations. | ||
| - Fail closed or require review when confidence is low or inputs are incomplete. | ||
| - Avoid exposing secrets, credentials, or unnecessary personal data. | ||
|
|
||
| ## Guardrails | ||
|
|
||
| Future architecture work should preserve these guardrails: | ||
|
|
||
| - Signed inputs for security-sensitive events. | ||
| - Explicit environment configuration with no shared-stage or production default secrets. | ||
| - Least-privilege integration credentials. | ||
| - Clear separation between demo simulation and production code paths. | ||
| - Auditable policy decisions and integration actions. | ||
| - Deterministic fallback behavior for missing, stale, or conflicting signals. | ||
|
|
||
| ## Non-goals | ||
|
|
||
| - Replacing customer IAM, UEM/MDM, DEX, NAC, SIEM, SOAR, or ITSM platforms. | ||
| - Building a generic autonomous agent that can take unrestricted external actions. | ||
| - Treating AI-generated explanations as policy decisions. | ||
| - Making production-readiness claims before deployment validation, load testing, and customer-specific integration review are complete. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,68 @@ | ||
| # Claim Boundaries | ||
| # SignalGrid Claim Boundaries | ||
|
|
||
| (Your content here) | ||
| SignalGrid should be described with clear MVP/demo boundaries. Use this document when preparing website copy, demos, sales materials, investor notes, or partner outreach. | ||
|
|
||
| ## What SignalGrid can claim today | ||
|
|
||
| SignalGrid can credibly claim that it: | ||
|
|
||
| - Provides a working MVP/demo path for posture-aware shared-device session decisions. | ||
| - Evaluates identity, device posture, session context, and policy inputs before returning an access outcome. | ||
| - Demonstrates deterministic outcomes for compliant, non-compliant, and unknown-posture scenarios. | ||
| - Fails closed for unknown posture in the current session-start path unless an explicit local/demo override is configured. | ||
| - Produces auditable decision context and demo-visible integration/action records. | ||
| - Includes simulated/demo workflows for NAC, SIEM, ITSM, and remediation-oriented narratives. | ||
| - Includes production-oriented packaging and runbook foundations that still require deployment-specific validation. | ||
|
|
||
| ## What is simulated or demo-only | ||
|
|
||
| The following should be labeled as simulated, deterministic demo behavior, or implementation foundation unless validated in a real pilot environment: | ||
|
|
||
| - Browser `/demo` scenarios and demo media outputs. | ||
| - Demo integration payload previews for NAC, SIEM, ITSM, and related action logs. | ||
| - Remediation attempts described in the current demo narrative. | ||
| - Any fallback storyboard media generated when browser capture is unavailable. | ||
| - Local/demo default keys or local-only script configuration. | ||
| - Buyer-safe sample data, seeded posture fixtures, and simulated frontline scenarios. | ||
|
|
||
| ## What not to claim yet | ||
|
|
||
| Do not claim the following until pilot or production validation exists for the target environment: | ||
|
|
||
| - Production readiness for a customer deployment. | ||
| - Guaranteed uptime, latency, scale, resilience, or compliance outcomes. | ||
| - Certified regulatory compliance such as HIPAA, SOC 2, ISO 27001, FedRAMP, or PCI. | ||
| - Fully automated remediation with verified post-remediation re-checks. | ||
| - Live customer integrations with a specific IAM, UEM/MDM, DEX, NAC, SIEM, ITSM, or badge system unless that integration has been configured and validated. | ||
| - Replacement of existing identity, endpoint, observability, network, ticketing, or device-management systems. | ||
| - AI-driven autonomous enforcement decisions. | ||
|
|
||
| ## Replacement boundaries | ||
|
|
||
| SignalGrid is positioned as a decision and orchestration layer between authentication, device posture, and enforcement systems. It does **not** replace: | ||
|
|
||
| | Existing category | Boundary language | | ||
| | --- | --- | | ||
| | IAM / identity provider | SignalGrid uses identity context; it does not replace identity proofing, authentication, or directory ownership. | | ||
| | UEM / MDM | SignalGrid consumes posture and enrollment signals; it does not manage full device lifecycle, configuration, or app deployment. | | ||
| | DEX / observability | SignalGrid can use operational signals; it does not replace broad employee-experience monitoring or telemetry platforms. | | ||
| | NAC / network enforcement | SignalGrid can request enforcement actions; it does not replace network control planes. | | ||
| | SIEM / SOAR | SignalGrid emits and enriches events; it does not replace security analytics, incident investigation, or enterprise SOAR governance. | | ||
| | ITSM | SignalGrid can create or update workflow records; it does not replace ticketing, change management, or service operations ownership. | | ||
|
|
||
| ## Safe phrasing | ||
|
|
||
| Use language like: | ||
|
|
||
| - “SignalGrid sits between authentication and enforcement to make shared-device access decisions based on runtime trust.” | ||
| - “The current MVP demonstrates deterministic access outcomes and auditable decision context.” | ||
| - “Pilot readiness depends on customer-specific integration validation, operational runbooks, and removal of local/demo defaults.” | ||
| - “Remediation is currently shown as a constrained demo narrative unless explicitly implemented and validated in the target environment.” | ||
|
|
||
| Avoid language like: | ||
|
|
||
| - “Production-ready today.” | ||
| - “Replaces your MDM/IAM/NAC/SIEM/ITSM stack.” | ||
| - “Fully autonomous remediation.” | ||
| - “Compliance guaranteed.” | ||
| - “AI decides who gets access.” |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,51 @@ | ||
| # Integration Priorities | ||
| # SignalGrid Integration Priorities | ||
|
|
||
| (Your content here) | ||
| SignalGrid integrates by consuming identity/posture/context signals, making a decision, and coordinating downstream actions. Current integration language should distinguish demo simulation from validated customer integrations. | ||
|
|
||
| ## Current simulated/demo integrations | ||
|
|
||
| The current repository can demonstrate integration behavior through deterministic demo flows and local payload previews for: | ||
|
|
||
| - Badge/session-start events. | ||
| - Device posture fixtures and telemetry-store reads. | ||
| - NAC-style quarantine/action records. | ||
| - SIEM-style security event records. | ||
| - ITSM-style ticket/action records. | ||
| - Demo media and storyboard outputs. | ||
|
|
||
| These are useful for explaining the control loop, but they should not be described as live production integrations unless connected and validated in a target environment. | ||
|
|
||
| ## First real integration targets | ||
|
|
||
| Prioritize the smallest integration set needed to prove a pilot workflow: | ||
|
|
||
| 1. **Identity / badge source** — confirm who is requesting access and map badge/session context to a user. | ||
| 2. **UEM/MDM or endpoint posture source** — provide fresh compliant, non-compliant, or unknown posture signals. | ||
| 3. **Audit/event sink** — preserve decision evidence in a customer-approved log destination. | ||
| 4. **ITSM workflow** — create reviewable tickets or tasks for denied or remediated sessions. | ||
| 5. **NAC or enforcement target** — only after policy, rollback, and safety boundaries are explicit. | ||
|
|
||
| ## Later integration targets | ||
|
|
||
| After the first pilot workflow is stable, consider: | ||
|
|
||
| - Additional MDM/UEM providers. | ||
| - Endpoint security and DEX telemetry providers. | ||
| - SIEM/SOAR enrichment and correlation workflows. | ||
| - HRIS or workforce context sources where appropriate and approved. | ||
| - Location/RTLS systems for shared-device return or zone context. | ||
| - Multiple enforcement systems for complex frontline environments. | ||
|
|
||
| ## Integration safety boundaries | ||
|
|
||
| - Do not use production credentials in demos. | ||
| - Do not call real webhooks from browser demo or media capture flows. | ||
| - Require explicit signing secrets and scoped credentials for shared/staging environments. | ||
| - Prefer read-only or audit-only pilot modes before write/enforcement actions. | ||
| - Use least-privilege service accounts and short rollback paths. | ||
| - Keep high-risk actions disabled until policy ownership and approval gates are clear. | ||
| - Record integration actions with enough detail for post-demo or post-pilot review. | ||
|
|
||
| ## Pilot sequencing recommendation | ||
|
|
||
| Start with identity, posture, and audit evidence. Add ticketing next. Add enforcement only when customer stakeholders agree on policy, blast radius, rollback, and success metrics. |
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a fresh GitHub runner,
npm ciinstalls@playwright/testbut does not provide the Chromium browser binary; in this repochromium.launch()reports thatnpx playwright installis required. Becausescripts/capture-demo-media.tscatches browser launch failures, writescapture-report.json, and exits successfully with only fallback storyboards, this workflow can pass the new “browser demo” validation without ever producing real browser screenshots/video. Add a Playwright browser install step (for example with dependencies) or assertbrowserAutomation.availablebefore accepting the report.Useful? React with 👍 / 👎.