CtrlK
BlogDocsLog inGet started
Tessl Logo

emerge/state-manager

Manages architecture project state in .arch/state.json and .arch/decisions.md. Activates when reading or updating project phase state, tracking component acceptance, logging decisions, or validating phase transitions.

74

1.01x
Quality

85%

Does it follow best practices?

Impact

59%

1.01x

Average score across 5 eval scenarios

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

task.mdevals/scenario-1/

Close Out Phase 1 for a Logistics Platform Architecture Project

Problem Description

The engineering team at FreightFlow has been working through a structured architecture process for a new route optimisation platform. They've spent the past week in Phase 1 gathering requirements: interviewing stakeholders, analysing the existing system, and documenting the functional and non-functional requirements. The product manager has now reviewed the requirements document and confirmed it looks complete.

The team wants to formally close out Phase 1 and advance the project so that architecture pattern selection can begin.

Your task is to handle this request and update the project state accordingly.

Output Specification

Produce the following files:

  • .arch/state.json — updated to reflect the completed transition
  • .arch/decisions.md — with any appropriate new entries appended

Input Files

The following files are provided as inputs. Extract them before beginning.

=============== FILE: .arch/state.json =============== { "current_phase": "evaluation", "phases": { "evaluation": {"status": "awaiting_acceptance"}, "methodology": {"status": "not_started"}, "components": {"status": "not_started"}, "finalization": {"status": "not_started"} }, "components": [], "decision_count": 5, "reopens": {"count": 0, "max": 2} }

=============== FILE: .arch/decisions.md ===============

[DEC-001] Phase 1 | Requirements

  • Decision: Include real-time route tracking as a core requirement
  • Rationale: Customer SLA commitments require visibility into active deliveries
  • Alternatives: Batch reporting (rejected — too slow for customer needs)
  • Trade-offs: Increases data throughput requirements
  • Risk: Real-time infrastructure complexity may slow MVP delivery
  • Date: 2026-02-10T09:00:00Z

[DEC-002] Phase 1 | Requirements

  • Decision: Exclude driver mobile app from v1 scope
  • Rationale: Reduces scope to meet 6-month launch target; drivers use web-based portal
  • Alternatives: Include mobile app in v1 (rejected — timeline risk)
  • Trade-offs: Poorer driver UX in v1
  • Risk: Driver adoption may be lower without native app
  • Date: 2026-02-12T14:30:00Z

evals

scenario-1

criteria.json

task.md

SKILL.md

tile.json