Santhosh Janardhanan
f87ccccc4d
address each point.
**Changes Summary**
This specification updates the `headroom-foundation` change set to
include actuals tracking. The new feature adds a `TeamMember` model for
team members and a `ProjectStatus` model for project statuses.
**Summary of Changes**
1. **Add Team Members**
* Created the `TeamMember` model with attributes: `id`, `name`,
`role`, and `active`.
* Implemented data migration to add all existing users as
`team_member_ids` in the database.
2. **Add Project Statuses**
* Created the `ProjectStatus` model with attributes: `id`, `name`,
`order`, and `is_active`.
* Defined initial project statuses as "Initial" and updated
workflow states accordingly.
3. **Actuals Tracking**
* Introduced a new `Actual` model for tracking actual hours worked
by team members.
* Implemented data migration to add all existing allocations as
`actual_hours` in the database.
* Added methods for updating and deleting actual records.
**Open Issues**
1. **Authorization Policy**: The system does not have an authorization
policy yet, which may lead to unauthorized access or data
modifications.
2. **Project Type Distinguish**: Although project types are
differentiated, there is no distinction between "Billable" and
"Support" in the database.
3. **Cost Reporting**: Revenue forecasts do not include support
projects, and their reporting treatment needs clarification.
**Implementation Roadmap**
1. **Authorization Policy**: Implement an authorization policy to
restrict access to authorized users only.
2. **Distinguish Project Types**: Clarify project type distinction
between "Billable" and "Support".
3. **Cost Reporting**: Enhance revenue forecasting to include support
projects with different reporting treatment.
**Task Assignments**
1. **Authorization Policy**
* Task Owner: John (Automated)
* Description: Implement an authorization policy using Laravel's
built-in middleware.
* Deadline: 2026-03-25
2. **Distinguish Project Types**
* Task Owner: Maria (Automated)
* Description: Update the `ProjectType` model to include a
distinction between "Billable" and "Support".
* Deadline: 2026-04-01
3. **Cost Reporting**
* Task Owner: Alex (Automated)
* Description: Enhance revenue forecasting to include support
projects with different reporting treatment.
* Deadline: 2026-04-15
70 lines
2.6 KiB
Markdown
70 lines
2.6 KiB
Markdown
---
|
|
name: "OPSX: New"
|
|
description: Start a new change using the experimental artifact workflow (OPSX)
|
|
category: Workflow
|
|
tags: [workflow, artifacts, experimental]
|
|
---
|
|
|
|
Start a new change using the experimental artifact-driven approach.
|
|
|
|
**Input**: The argument after `/opsx:new` is the change name (kebab-case), OR a description of what the user wants to build.
|
|
|
|
**Steps**
|
|
|
|
1. **If no input provided, ask what they want to build**
|
|
|
|
Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
|
|
> "What change do you want to work on? Describe what you want to build or fix."
|
|
|
|
From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
|
|
|
|
**IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
|
|
|
|
2. **Determine the workflow schema**
|
|
|
|
Use the default schema (omit `--schema`) unless the user explicitly requests a different workflow.
|
|
|
|
**Use a different schema only if the user mentions:**
|
|
- A specific schema name → use `--schema <name>`
|
|
- "show workflows" or "what workflows" → run `openspec schemas --json` and let them choose
|
|
|
|
**Otherwise**: Omit `--schema` to use the default.
|
|
|
|
3. **Create the change directory**
|
|
```bash
|
|
openspec new change "<name>"
|
|
```
|
|
Add `--schema <name>` only if the user requested a specific workflow.
|
|
This creates a scaffolded change at `openspec/changes/<name>/` with the selected schema.
|
|
|
|
4. **Show the artifact status**
|
|
```bash
|
|
openspec status --change "<name>"
|
|
```
|
|
This shows which artifacts need to be created and which are ready (dependencies satisfied).
|
|
|
|
5. **Get instructions for the first artifact**
|
|
The first artifact depends on the schema. Check the status output to find the first artifact with status "ready".
|
|
```bash
|
|
openspec instructions <first-artifact-id> --change "<name>"
|
|
```
|
|
This outputs the template and context for creating the first artifact.
|
|
|
|
6. **STOP and wait for user direction**
|
|
|
|
**Output**
|
|
|
|
After completing the steps, summarize:
|
|
- Change name and location
|
|
- Schema/workflow being used and its artifact sequence
|
|
- Current status (0/N artifacts complete)
|
|
- The template for the first artifact
|
|
- Prompt: "Ready to create the first artifact? Run `/opsx:continue` or just describe what this change is about and I'll draft it."
|
|
|
|
**Guardrails**
|
|
- Do NOT create any artifacts yet - just show the instructions
|
|
- Do NOT advance beyond showing the first artifact template
|
|
- If the name is invalid (not kebab-case), ask for a valid name
|
|
- If a change with that name already exists, suggest using `/opsx:continue` instead
|
|
- Pass --schema if using a non-default workflow
|