Releases: dcsil/PyGuard
Demo1 — Surface Product & Proof of Concept (A4)
Overview of this Release
Direct Links
Executive Summary
This release delivers our Demo1 Surface Product for CSC454 A4: a locally runnable, chat-based autonomous assistant that executes a multi-step compliance follow-up workflow from a single user instruction. The system performs real web research, generates a structured compliance report (including a shareable Google Doc link when applicable), and executes real follow-up actions such as sending an email and scheduling a calendar meeting. Alongside the working prototype, we provide a baseline Critical User Journey (CUJ) with timed steps, context-switch tracking, friction severity ratings, and screenshot evidence, establishing measurable baselines for future friction reduction sprints.
Contextual Details (A4: Proof of Concept + Validation Scope)
Primary interaction validated: From one instruction, the agent completes research → report → communication (email + meeting scheduling) end-to-end with real functionality (no placeholder logic).
Proof-of-concept scope: We define what “working” means for this sprint and list known constraints/accepted limitations in the Proof of Concept Scope artifact, including deferred capabilities (e.g., no flagged-transaction ingestion, no file upload) and current workflow risks (e.g., limited cancel/edit controls, confirmation gating improvements needed).
Baseline CUJ outcome (required path only):
- Completion time: 678 seconds (11m 18s)
- Context switches: 0 (optional verification excluded)
- Severe friction steps: 0 (per-step severity ratings)
These metrics are captured in the Baseline CUJ artifact and will be used as the baseline for the next demo’s friction reduction goals.
Issue Activity (Since Sprint Start)
Issues created/resolved in this sprint:
- ✅ Closed: PyGuard-Agentic-Agent#1, PyGuard#4
Strategic Updates (Architecture / Roadmap)
Architecture (current):
- Reinforced logical separation between:
- UI tier: chat interface for instruction input + result display
- Logic tier: backend agent/orchestrator (planning + tool execution + formatting)
- Data/Integration tier: external services/tools (web research sources, Google Docs, Gmail, Google Calendar)
Roadmap adjustments (based on baseline CUJ evidence):
- Prioritize friction reduction in the next sprint:
- Add stop/cancel/edit during execution
- Add review & confirm before email/meeting side effects
- Add step-based progress and stronger action receipts to reduce black-box waiting and optional verification
- Add prompt templates/guided inputs to reduce instruction ambiguity
Use Case Changes (Approval Required)
No changes to the primary use case were made in this sprint.
Primary use case remains: single instruction → research → report → follow-up communication (email + meeting).
(Any future changes to primary use cases will be brought to the instructor for formal approval.)
Cloud Architecture & Deployment
Overview of This Release
This release represents the formal submission snapshot for Assignment 3: Cloud Architecture & Deployment.
During this sprint, our team transitioned our previously local, decoupled MVP into a live, production-grade cloud deployment, and implemented a hands-off GitHub Actions delivery pipeline (“Deployment Zen”). We also documented our cloud blueprint (system boundaries, orchestration, data/control planes), and our secret management strategy.
Direct Links
- Release Landing Page (this README)
- Cloud Architecture Diagram
- Reflections
- Deployment Workflow Summary
- Live-Deployed Application URL
- Code Repository
- GitHub Actions Workflow (deploy.yml in code repo)
Contextual Details
What Shipped (A3 Scope)
- Blueprint First: A cloud architecture diagram defining system boundaries, service orchestration, and the split between data plane and control plane.
- Deployment Zen: A minimal, reliable CI/CD pipeline where a tag/release trigger automatically deploys to our cloud provider (e.g., Railway).
- Production-Grade Access: HTTPS ingress, stable public endpoints, and authenticated backend access paths where applicable.
- Secret Management: Zero hardcoded credentials; secrets are stored in GitHub Secrets and/or the cloud runtime’s environment variables.
MVP Primitives vs Futurist Vectors (Architectural Evolution)
Immediate MVP primitives (Day One, shipped now):
- Decoupled frontend service (React + Vite build)
- Decoupled backend service (Node/Express API)
- Managed Postgres persistence (via Prisma)
- GitHub Actions workflow for automated deploy
- Environment-based configuration (no secrets in repo)
Futurist scalability vectors (documented, not over-engineered yet):
- CDN/edge caching for static assets
- API gateway / WAF / rate limiting layer
- Horizontal scaling and autoscaling policies
- Background jobs + queue for async tasks
- Observability (centralized logs/metrics/tracing)
- Multi-region + HA posture, migration plan, DR strategy
Architecture Snapshot
Data Plane (Runtime)
User → Frontend (HTTPS) → Backend API (HTTPS) → Managed Postgres (SQL via Prisma)
(See: diagram.(png|jpg))
Control Plane (Delivery)
Git Tag / GitHub Release → GitHub Actions → Cloud Deploy (provider CLI/API) → Live Services Updated
(See: workflow.md + deploy.yml link)
Deployment Pipeline Summary
- Trigger:
<e.g., push tag v1.0.0-A3 OR publish GitHub Release> - Workflow file:
.github/workflows/deploy.yml(in the code repo) - Core steps (high-level):
- Checkout repository
- Install dependencies
- Build frontend (if applicable)
- Deploy frontend + backend services to cloud provider
- Run migrations (if applicable / safe in workflow)
- Secrets:
<LIST_SECRET_NAMES_ONLY, e.g., RAILWAY_TOKEN, DATABASE_URL, etc.>
Stored in GitHub Secrets and injected at runtime.
Security & Secret Management
- ✅ No hardcoded credentials in source control
- ✅ Deployment auth is via GitHub Secrets
- ✅ Runtime configuration uses environment variables
- ✅ DB credentials and tokens are stored in the cloud provider’s secret store and/or GitHub Secrets (documented in
workflow.md)
Feedback-Driven Refinements (A2 → A3)
This deployment reflects specific maturation from our A2 CUJ findings and peer feedback:
- Improved stability and “works for the world” readiness (public endpoint, consistent runtime environment)
- Reduced manual steps and context switching via automated deployment
- Clearer separation of concerns between frontend/backend/persistence
(Full synthesis:reflections.md)
Issue Activity Summary
No major issues during the release. Minor fixes were tracked through PRs and issue assignments to maintain an audit trail.
Strategic Updates
Architecture
- Maintained decoupled services, now production-deployed with managed persistence.
- Standardized diagram notation using industry-standard cloud iconography.
Roadmap
- Short-term: tighten monitoring/logging, add rate limiting, finalize rollback strategy
- Mid-term: async job queue for long-running tasks, CDN caching, improved HA posture
Notes
- Documentation/Artifacts only in this release repository (per submission rules).
The implementation code is hosted separately and linked above. - This release serves as an immutable grading snapshot for Assignment 3.
- Release tag:
v1.0.0-A3(semantic versioning)
Repository Manifest (Recommended)
Rapid MVP & CUJ Framework
Overview of This Release
This release represents the formal submission snapshot for Assignment 2: Rapid MVP & CUJ Framework.
During this sprint, our team built an intentionally lean MVP—the Classroom Presentation Randomizer—and conducted a Critical User Journey (CUJ) analysis to surface real-world usability friction.
Direct Links
- Sprint Landing Page (README)
- CUJ Framework Document
- CUJ Evidence & Screenshots
- Post-Mortem: Lessons Learned (Done vs Usable)
- Team Principles Reflection (Conflict, Accountability, Feedback)
Contextual Details
MVP Scope
The Classroom Presentation Randomizer is a locally runnable, decoupled web application designed to assist instructors in managing in-class presentations. Core functionality includes randomized team selection, visual tracking of presented teams, and a dual-phase timer for presentations and Q&A.
The MVP was intentionally kept minimal to maximize the effectiveness of the CUJ analysis and highlight friction in realistic classroom usage.
CUJ Focus
Our CUJ analysis prioritizes:
- Quantifying user friction through step-by-step task breakdowns
- Identifying context switches (both physical and cognitive)
- Distinguishing between technically “done” features and practically “usable” workflows
- Proposing targeted, low-scope improvements grounded in observed friction
Issue Activity Summary
- No major issue during the release.
Strategic Updates
Architecture
- Maintained a decoupled frontend/backend architecture, aligned with future cloud deployment requirements in A3.
- No changes were made to core use cases during this sprint.
Roadmap
- No roadmap changes were introduced in this release.
- Findings from the CUJ analysis will inform potential usability improvements in future iterations.
Notes
- This release contains documentation and artifacts only in accordance with the submission requirements.
- The implementation code for the MVP is hosted in a separate repository and linked in the sprint README.
- This release serves as an immutable grading snapshot for Assignment 2.
Tech Choices, Architecture Diagram, Roadmap
Overview of This Release
- Added README.md, tooling.md, malek_sibai.md, yunling_zhang.md, diversity.md: [No issues were added for this Assignment but will start adding issues starting next assignment]