Archived completed OpenSpec change after successful deployment. The template path fix has been applied to specs and is now in production. Change archived as: 2026-01-12-fix-coverletter-template-path Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
198 lines
7.6 KiB
Markdown
198 lines
7.6 KiB
Markdown
# application-management Specification Delta
|
|
|
|
## Purpose
|
|
Document updates to application-management capability to include lifecycle management and archival support.
|
|
|
|
## ADDED Requirements
|
|
|
|
### Requirement: Application Lifecycle Management
|
|
|
|
The system SHALL support the complete lifecycle of applications from creation through archival with clear state tracking.
|
|
|
|
#### Scenario: Application progresses through lifecycle states
|
|
|
|
- **WHEN** application is created with `/new-application`
|
|
- **THEN** Status is set to "Draft" in Metadata section
|
|
- **AND** application is stored in `applications/pending/` folder
|
|
- **WHEN** application is archived with `/archive-application rejected`
|
|
- **THEN** Status is updated to "Rejected (Archived: [timestamp])"
|
|
- **AND** application is moved to `applications/rejected/` folder
|
|
- **WHEN** application is archived with `/archive-application not-interested`
|
|
- **THEN** Status is updated to "Not Interested (Archived: [timestamp])"
|
|
- **AND** application is moved to `applications/not-interested/` folder
|
|
|
|
#### Scenario: Folder organization reflects application state
|
|
|
|
- **WHEN** viewing applications directory structure
|
|
- **THEN** active applications are in `applications/pending/`
|
|
- **AND** rejected applications are in `applications/rejected/`
|
|
- **AND** withdrawn applications are in `applications/not-interested/`
|
|
- **AND** all folders use same naming convention (YYYY-MM-DD-Company-JobTitle)
|
|
|
|
#### Scenario: Status field tracks current state
|
|
|
|
- **WHEN** application exists in any folder
|
|
- **THEN** application.md contains Status field in Metadata section
|
|
- **AND** Status field accurately reflects current lifecycle state
|
|
- **AND** Archived states include timestamp of archival
|
|
- **AND** Status field format is: `- **Status**: [State] (Archived: [timestamp])`
|
|
|
|
#### Scenario: Application structure preserved across lifecycle
|
|
|
|
- **WHEN** application moves between lifecycle states
|
|
- **THEN** all files are preserved (application.md, generated documents)
|
|
- **AND** all folders are preserved (input/, attachments/)
|
|
- **AND** folder name remains unchanged
|
|
- **AND** only Status field in Metadata section is modified
|
|
|
|
---
|
|
|
|
### Requirement: Archive Folder Support
|
|
|
|
The system SHALL provide dedicated folders for archived applications organized by outcome.
|
|
|
|
#### Scenario: Rejected applications folder
|
|
|
|
- **WHEN** application is rejected by company
|
|
- **THEN** application is moved to `applications/rejected/` folder
|
|
- **AND** folder is created if it doesn't already exist
|
|
- **AND** folder contains applications rejected by companies
|
|
|
|
#### Scenario: Not-interested applications folder
|
|
|
|
- **WHEN** user decides not to pursue application
|
|
- **THEN** application is moved to `applications/not-interested/` folder
|
|
- **AND** folder is created if it doesn't already exist
|
|
- **AND** folder contains applications user withdrew from
|
|
|
|
#### Scenario: Archive folders maintain chronological organization
|
|
|
|
- **WHEN** multiple applications are archived
|
|
- **THEN** date prefix (YYYY-MM-DD) allows chronological sorting
|
|
- **AND** folders can be easily browsed by date
|
|
- **AND** organization matches pending folder structure
|
|
|
|
---
|
|
|
|
### Requirement: Status Field Management
|
|
|
|
The system SHALL maintain accurate Status field in application.md throughout lifecycle.
|
|
|
|
#### Scenario: Status field exists in template
|
|
|
|
- **WHEN** new application is created from template
|
|
- **THEN** Metadata section includes Status field
|
|
- **AND** Status field is formatted: `- **Status**: Draft`
|
|
- **AND** Status field is on line 12 of application.md
|
|
|
|
#### Scenario: Status field is preserved during population
|
|
|
|
- **WHEN** `/populate-application` analyzes documents
|
|
- **THEN** Status field in Metadata section is not modified
|
|
- **AND** user can manually update Status as needed
|
|
- **AND** Status field persists through multiple population runs
|
|
|
|
#### Scenario: Status field is updated on archival
|
|
|
|
- **WHEN** application is archived
|
|
- **THEN** Status field is updated with new state and timestamp
|
|
- **AND** old Status value is replaced (not appended)
|
|
- **AND** timestamp format is consistent (YYYY-MM-DD HH:MM)
|
|
|
|
---
|
|
|
|
## MODIFIED Requirements
|
|
|
|
### Requirement: Application Folder Structure
|
|
|
|
The application folder structure SHALL include archive folders in addition to the pending folder for organizing applications by lifecycle state.
|
|
|
|
#### Scenario: Complete folder hierarchy
|
|
|
|
- **WHEN** application framework is in use
|
|
- **THEN** folder structure is:
|
|
```
|
|
applications/
|
|
├── pending/ # Active applications
|
|
├── rejected/ # Rejected by company
|
|
└── not-interested/ # User withdrew
|
|
```
|
|
- **AND** each folder contains application subfolders with format: `YYYY-MM-DD-Company-JobTitle/`
|
|
- **AND** archive folders are created on-demand when first needed
|
|
|
|
---
|
|
|
|
## Cross-References
|
|
|
|
### Related Capabilities
|
|
|
|
- **application-archiving** (NEW): Provides `/archive-application` command for moving applications to archive folders
|
|
- **applicant-profile**: Profile information is preserved in archived applications for future reference
|
|
- **cover-letter-generation**: Generated cover letters trigger safety checks during archiving
|
|
- **application-email**: Generated emails trigger safety checks during archiving
|
|
- **application-validation**: Validation ensures applications are complete, but archived applications may be incomplete
|
|
|
|
### Integration Points
|
|
|
|
- Archive folders created by `application-archiving` capability
|
|
- Status field updated by `application-archiving` capability
|
|
- Application folder structure maintained by both capabilities
|
|
- Generated document detection shared between capabilities
|
|
|
|
---
|
|
|
|
## Technical Notes
|
|
|
|
### Lifecycle State Diagram
|
|
|
|
```
|
|
[Created] ──/new-application──> [Draft (pending/)]
|
|
│
|
|
├──(user works on application)
|
|
├──/populate-application
|
|
├──/validate-application
|
|
├──/write-cover-letter
|
|
├──/write-application-email
|
|
├──(user submits application)
|
|
│
|
|
├──/archive-application rejected
|
|
│ └─> [Rejected (rejected/)]
|
|
│
|
|
└──/archive-application not-interested
|
|
└─> [Not Interested (not-interested/)]
|
|
```
|
|
|
|
### Status Field Values
|
|
|
|
- **Draft**: Initial state, application being prepared
|
|
- **Rejected (Archived: [timestamp])**: Company rejected application
|
|
- **Not Interested (Archived: [timestamp])**: User decided not to pursue
|
|
|
|
**Note**: Additional states may be used by user (e.g., "Submitted", "Interview Scheduled") but are not enforced by system.
|
|
|
|
---
|
|
|
|
## Backwards Compatibility
|
|
|
|
**No breaking changes:**
|
|
- Existing applications in `pending/` folder remain valid
|
|
- Archive folders are optional and created on-demand
|
|
- Status field already exists in template (line 12)
|
|
- No changes to existing command behavior
|
|
|
|
**Forward compatible:**
|
|
- Old applications can be archived without modification
|
|
- New applications work with archiving from creation
|
|
- Archive structure supports future enhancements (e.g., accepted folder)
|
|
|
|
---
|
|
|
|
## Validation
|
|
|
|
This specification delta can be validated by:
|
|
|
|
1. Running `openspec validate archive-applications --strict`
|
|
2. Verifying integration with application-archiving capability
|
|
3. Checking that existing application-management requirements still apply
|
|
4. Confirming no conflicts with other capabilities
|