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
135 lines
4.3 KiB
Markdown
135 lines
4.3 KiB
Markdown
---
|
|
name: "OPSX: Sync"
|
|
description: Sync delta specs from a change to main specs
|
|
category: Workflow
|
|
tags: [workflow, specs, experimental]
|
|
---
|
|
|
|
Sync delta specs from a change to main specs.
|
|
|
|
This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
|
|
|
|
**Input**: Optionally specify a change name after `/opsx:sync` (e.g., `/opsx:sync add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
|
|
|
|
**Steps**
|
|
|
|
1. **If no change name provided, prompt for selection**
|
|
|
|
Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
|
|
|
|
Show changes that have delta specs (under `specs/` directory).
|
|
|
|
**IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
|
|
|
|
2. **Find delta specs**
|
|
|
|
Look for delta spec files in `openspec/changes/<name>/specs/*/spec.md`.
|
|
|
|
Each delta spec file contains sections like:
|
|
- `## ADDED Requirements` - New requirements to add
|
|
- `## MODIFIED Requirements` - Changes to existing requirements
|
|
- `## REMOVED Requirements` - Requirements to remove
|
|
- `## RENAMED Requirements` - Requirements to rename (FROM:/TO: format)
|
|
|
|
If no delta specs found, inform user and stop.
|
|
|
|
3. **For each delta spec, apply changes to main specs**
|
|
|
|
For each capability with a delta spec at `openspec/changes/<name>/specs/<capability>/spec.md`:
|
|
|
|
a. **Read the delta spec** to understand the intended changes
|
|
|
|
b. **Read the main spec** at `openspec/specs/<capability>/spec.md` (may not exist yet)
|
|
|
|
c. **Apply changes intelligently**:
|
|
|
|
**ADDED Requirements:**
|
|
- If requirement doesn't exist in main spec → add it
|
|
- If requirement already exists → update it to match (treat as implicit MODIFIED)
|
|
|
|
**MODIFIED Requirements:**
|
|
- Find the requirement in main spec
|
|
- Apply the changes - this can be:
|
|
- Adding new scenarios (don't need to copy existing ones)
|
|
- Modifying existing scenarios
|
|
- Changing the requirement description
|
|
- Preserve scenarios/content not mentioned in the delta
|
|
|
|
**REMOVED Requirements:**
|
|
- Remove the entire requirement block from main spec
|
|
|
|
**RENAMED Requirements:**
|
|
- Find the FROM requirement, rename to TO
|
|
|
|
d. **Create new main spec** if capability doesn't exist yet:
|
|
- Create `openspec/specs/<capability>/spec.md`
|
|
- Add Purpose section (can be brief, mark as TBD)
|
|
- Add Requirements section with the ADDED requirements
|
|
|
|
4. **Show summary**
|
|
|
|
After applying all changes, summarize:
|
|
- Which capabilities were updated
|
|
- What changes were made (requirements added/modified/removed/renamed)
|
|
|
|
**Delta Spec Format Reference**
|
|
|
|
```markdown
|
|
## ADDED Requirements
|
|
|
|
### Requirement: New Feature
|
|
The system SHALL do something new.
|
|
|
|
#### Scenario: Basic case
|
|
- **WHEN** user does X
|
|
- **THEN** system does Y
|
|
|
|
## MODIFIED Requirements
|
|
|
|
### Requirement: Existing Feature
|
|
#### Scenario: New scenario to add
|
|
- **WHEN** user does A
|
|
- **THEN** system does B
|
|
|
|
## REMOVED Requirements
|
|
|
|
### Requirement: Deprecated Feature
|
|
|
|
## RENAMED Requirements
|
|
|
|
- FROM: `### Requirement: Old Name`
|
|
- TO: `### Requirement: New Name`
|
|
```
|
|
|
|
**Key Principle: Intelligent Merging**
|
|
|
|
Unlike programmatic merging, you can apply **partial updates**:
|
|
- To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios
|
|
- The delta represents *intent*, not a wholesale replacement
|
|
- Use your judgment to merge changes sensibly
|
|
|
|
**Output On Success**
|
|
|
|
```
|
|
## Specs Synced: <change-name>
|
|
|
|
Updated main specs:
|
|
|
|
**<capability-1>**:
|
|
- Added requirement: "New Feature"
|
|
- Modified requirement: "Existing Feature" (added 1 scenario)
|
|
|
|
**<capability-2>**:
|
|
- Created new spec file
|
|
- Added requirement: "Another Feature"
|
|
|
|
Main specs are now updated. The change remains active - archive when implementation is complete.
|
|
```
|
|
|
|
**Guardrails**
|
|
- Read both delta and main specs before making changes
|
|
- Preserve existing content not mentioned in delta
|
|
- If something is unclear, ask for clarification
|
|
- Show what you're changing as you go
|
|
- The operation should be idempotent - running twice should give same result
|