# 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