ios-worker

name	ios-worker
description	Implements and tests SwiftUI views, navigation flows, and shared iOS design-system work for ADE

iOS Worker

NOTE: Startup and cleanup are handled by worker-base. This skill defines the WORK PROCEDURE.

When to Use This Skill

Use for features that are primarily iOS UI work inside apps/ios/ADE/, including:

• SwiftUI screen extraction and file splitting
• mobile information architecture changes inside existing tabs
• shared iOS design-system and Liquid Glass component work
• accessibility and motion-polish work
• iOS-side performance cleanup in view code
• iOS tests in apps/ios/ADETests/

Do not use this skill for desktop sync-host, shared contract, SyncService, RemoteModels, or database features. Those belong to a sync/backend worker.

Work Procedure

1. Understand the Feature

Read the feature description, preconditions, expectedBehavior, and verificationSteps carefully. Then:

• Read mission.md for overall mission context
• Read AGENTS.md for boundaries and conventions
• Read .factory/library/architecture.md for app architecture and patterns
• Read .factory/library/tab-parity.md and .factory/library/performance.md when the feature touches parity or lag-sensitive flows
• Read the existing code files you'll be modifying in full
• If the feature touches a tab other than Lanes, still read the relevant Lanes benchmark components to match the established mobile quality bar

2. Plan the Changes

Before writing any code:

• List every file you'll create or modify
• Identify which existing code to preserve vs. rewrite
• Note which existing syncService methods the views need to call
• Identify which shared components should be promoted into Views/Components/ instead of duplicated inside a tab
• Check that your plan stays on the iOS/UI side of the boundary; if the feature needs SyncService, RemoteModels, Database, or desktop host changes, stop and return to the orchestrator

3. Write Tests First (Red)

For any testable logic (filters, computed properties, data transformations, directory grouping):

• Add test cases to ADETests.swift (the single test file)
• Tests should fail initially (red phase)
• Use @testable import ADE and XCTest patterns matching existing tests
• Focus on logic tests, not UI rendering tests

4. Implement (Green)

Write the SwiftUI code:

• File organization: Each major screen or slice gets its own file under the relevant tab folder (Views/Lanes/, Views/Files/, Views/Work/, Views/PRs/, Views/Settings/). Keep files under 500 lines; if a feature leaves a file bigger than that, split again before handing off.
• Design system: Use ADEColor.*, ADEMotion.*, .adeGlassCard(), .adeInsetField(), .adeNavigationGlass(), .adeScreenBackground(), ADENoticeCard, ADEStatusPill, ADEEmptyStateView, ADESkeletonView, ADECardSkeleton, and shared glass helpers instead of ad-hoc styling.
• Liquid Glass: Prefer shared glass primitives and matched navigation transitions over one-off background/stroke recipes. When adding repeated chips or buttons, prefer reusable shared components instead of tab-local copies.
• Accessibility: Add .accessibilityLabel to all interactive elements. Use ADEMotion which respects reduceMotion. Preserve .sensoryFeedback on appropriate interactions.
• Data access: Use @EnvironmentObject var syncService: SyncService. Call existing SyncService methods — never add new ones.
• State management: Use @State for local state. Prefer debounced .task(id: syncService.localStateRevision) patterns matching the Lanes benchmark when reloading cached projections.
• Performance: Use lazy containers for large lists, avoid heavy parsing/computation in body, cache expensive derived values in state/view-model helpers, and preserve source-tab context on return navigation.
• Boundary: No changes to SyncService.swift, RemoteModels.swift, Database.swift, desktop services, or shared sync contracts from this skill.

5. Update Xcode Project

When creating new Swift files, you MUST add them to the Xcode project:

• Edit apps/ios/ADE.xcodeproj/project.pbxproj to add file references and build phase entries
• Follow the existing pattern in the pbxproj for file references (PBXFileReference, PBXBuildFile, PBXGroup children)
• Alternatively, if the project uses folder references, ensure files are in the correct directory

6. Verify

Run these commands and fix any issues:

# Mission simulator target
DESTINATION="platform=iOS Simulator,name=iPhone 17 Pro,OS=26.3.1"

# Build / test / analyzer
xcodebuild build -project apps/ios/ADE.xcodeproj -scheme ADE -destination "$DESTINATION" -quiet
xcodebuild test -project apps/ios/ADE.xcodeproj -scheme ADE -destination "$DESTINATION" -quiet
xcodebuild -project apps/ios/ADE.xcodeproj -scheme ADE -destination "$DESTINATION" -derivedDataPath /tmp/ade-build analyze

# Check file sizes (no file should exceed 500 lines)
find apps/ios/ADE -name '*.swift' -exec wc -l {} + | sort -rn | head -20

All must pass for the touched surface. If build or tests fail, fix immediately. If a failure is clearly pre-existing and outside the feature boundary, return to the orchestrator with evidence instead of hand-waving past it.

7. Manual Verification

Do the strongest manual verification the feature allows:

• Trace the full data flow from SyncService through the view hierarchy
• Verify syncService method calls and model property names match the existing API exactly
• If the feature can be checked in the simulator without a live host, do so
• If the feature depends on live sync data, validate against the paired desktop host when that service is available in the mission
• Check that navigation back/return preserves the source context for mobile triage flows
• Ensure no unused imports, dead code, placeholder copy, or TODO markers remain

8. Commit

Commit with a clear message describing what was implemented.

Example Handoff

{
  "salientSummary": "Split the Work tab into mobile-first subviews, added a reusable glass section/chip stack in Views/Components, and stabilized session list/detail navigation so filters and context survive round-trips. Build, tests, and analyzer passed on the mission simulator target.",
  "whatWasImplemented": "Refactored WorkTabView.swift into focused files under Views/Work/, promoted reusable glass chips/section containers into Views/Components/, and updated the Work list/detail flows to preserve lane/search/filter context when opening sessions and returning. The new UI keeps chat/terminal sessions readable on iPhone, uses shared glass styling, and removes several hot-path computations from SwiftUI body evaluation.",
  "whatWasLeftUndone": "",
  "verification": {
    "commandsRun": [
      {
        "command": "xcodebuild build -project apps/ios/ADE.xcodeproj -scheme ADE -destination 'platform=iOS Simulator,name=iPhone 17 Pro,OS=26.3.1' -quiet",
        "exitCode": 0,
        "observation": "Build succeeded with no errors or warnings"
      },
      {
        "command": "xcodebuild test -project apps/ios/ADE.xcodeproj -scheme ADE -destination 'platform=iOS Simulator,name=iPhone 17 Pro,OS=26.3.1' -quiet",
        "exitCode": 0,
        "observation": "The iOS test suite passed on the mission destination"
      },
      {
        "command": "xcodebuild -project apps/ios/ADE.xcodeproj -scheme ADE -destination 'platform=iOS Simulator,name=iPhone 17 Pro,OS=26.3.1' -derivedDataPath /tmp/ade-build analyze",
        "exitCode": 0,
        "observation": "Static analysis completed without blocking diagnostics"
      },
      {
        "command": "find apps/ios/ADE -name '*.swift' -exec wc -l {} + | sort -rn | head -20",
        "exitCode": 0,
        "observation": "New and modified Swift files stayed within the file-size limit after extraction"
      }
    ],
    "interactiveChecks": [
      {
        "action": "Traced session list → session detail → back navigation on the refactored Work surface",
        "observed": "The source lane/filter/search context remained intact after returning from detail"
      },
      {
        "action": "Reviewed all promoted shared components and the new Work subviews against the existing SyncService API",
        "observed": "All property and method accesses remained within the existing iOS/UI boundary and matched current signatures"
      }
    ]
  },
  "tests": {
    "added": []
  },
  "discoveredIssues": []
}

When to Return to Orchestrator

• The feature requires changes to SyncService, RemoteModels, Database, desktop services, or shared sync contracts
• The existing API/data shape cannot support the feature without backend or contract work
• Xcode project state becomes corrupted or unrecoverable
• Build/test/analyzer failures are outside the touched iOS surface and cannot be repaired safely inside the feature boundary
• A file still exceeds 500 lines after a reasonable split attempt