Files
Bewerbungszauberer/openspec/changes/archive-applications/specs/application-management/spec.md
T
gurixandClaude Sonnet 4.5 c91999d78c chore: archive fix-coverletter-template-path change
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>
2026-01-12 21:51:51 +01:00

7.6 KiB

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

  • 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