Delivery & assurance

Deliver:

•voice, text, image, audio, and file capture;

•original artifact preservation;

•transcription;

•human-reviewed task extraction;

•task and project creation;

•assignment;

•status workflow;

•checklists;

•progress updates;

•evidence uploads;

•creator or reviewer reconciliation;

•revision requests;

•verification;

•knowledge proposal;

•Point Preserve dashboard;

•audit events;

•basic notifications;

•seeded Point Preserve configuration and sample data.

Add:

•proactive maintenance suggestions;

•recurring issue detection;

•duplicate detection;

•operational question answering;

•asset and location history queries;

•bottleneck detection;

•recommendation drafts;

•richer executive intelligence.

Do not define Phase 2 merely as additional task-completion features.

Reserve Phase 2 for materially broader platform capabilities or cross-domain operational systems discovered through validated use.

Produce deliverables in this order:

1.Executive summary.

2.Repository and architecture inventory.

3.Duplication analysis.

4.Gap analysis.

5.Proposed canonical placement.

6.Capability dependency map.

7.CAPE mapping.

8.Reuse, extend, or create decision table.

9.ADR plan.

10.Proposed canonical capability registry changes.

11.Proposed canonical object changes.

12.Proposed event contracts.

13.Proposed API contracts.

14.Identity and permission model.

15.Artifact and provenance model.

16.Voice and transcription architecture.

17.Knowledge integration architecture.

18.Point Preserve reference implementation design.

19.Data migration and compatibility plan.

20.Security, privacy, and safety review.

21.Testing strategy.

22.Observability strategy.

23.Documentation plan.

24.Rollout and rollback plan.

25.Implementation plan with sequenced work packages.

26.Definition of done.

27.Explicit list of unresolved questions, assumptions, and risks.

Do not begin implementation before the planning gate required by the repository has been satisfied.

Once the architecture plan and ADRs are approved:

1.Create or update canonical contracts first.

2.Implement database migrations.

3.Implement shared services.

4.Implement event producers and consumers.

5.Implement APIs and permission enforcement.

6.Implement ingestion adapters.

7.Implement voice and transcription flows.

8.Implement task workflow and reconciliation.

9.Implement evidence handling.

10.Implement knowledge proposal flows.

11.Implement the Point Preserve reference interface.

12.Seed Point Preserve roles, locations, categories, templates, and examples.

13.Add tests.

14.Add instrumentation.

15.Update architecture documentation and registries.

16.Update changelog and NEXT.md.

17.Run full verification.

18.Produce a final implementation report.

Use small, reviewable commits.

Do not mix unrelated repository cleanup into the implementation.

At minimum, verify these outcomes:

•A user can record a voice request and produce a reviewed task.

•A user can upload an existing voice memo and preserve both audio and transcript.

•A user can upload an image and provide spoken or typed instructions.

•A user can upload a document and extract multiple proposed tasks.

•An Apple Note export can be accepted as an artifact.

•Embedded attachments are preserved when exposed by the source format.

•Unsupported embedded media produces a transparent limitation notice.

•AI-generated fields remain editable before confirmation.

•The original request remains accessible.

•Low-confidence consequential fields require review.

•Duplicate open tasks are surfaced.

•A single source can generate a project with child tasks.

•A task can be assigned.

•The assignee can accept it.

•The assignee can update status.

•Checklist items can be checked off.

•Voice and photo progress updates can be added.

•A blocked task records the blocker.

•Recurring tasks can generate future instances according to policy.

•Required evidence prevents premature verification.

•The assignee can submit work for review.

•The creator or authorized reviewer can approve it.

•The reviewer can request revision.

•Revision history remains visible.

•Completion can be reopened by an authorized user.

•Every material status change appears in the audit trail.

•Verified work can generate a proposed knowledge record.

•The proposal links back to its source task and evidence.

•Duplicate knowledge is detected.

•Unapproved AI output is not labeled canonical.

•Approved knowledge becomes available to authorized operational search.

•Staff see only permitted tasks.

•Vendors see only work assigned or shared with them.

•Unauthorized users cannot verify work.

•Unauthorized users cannot publish knowledge.

•Tenant data remains isolated.

•The plug-in uses canonical identity.

•The plug-in uses canonical artifacts and evidence.

•The plug-in uses canonical workflow services where available.

•Events conform to the registry.

•No duplicate foundational service is introduced.

•Point Preserve-specific logic remains configurable rather than embedded in the shared core.

The work is complete only when:

•the duplication analysis has been documented;

•canonical placement is confirmed;

•required ADRs are approved;

•all new or changed objects have versioned contracts;

•all events have versioned contracts;

•the five Phase 1 skills function end-to-end;

•Point Preserve is implemented as a reference configuration;

•voice, text, image, audio, and file capture work;

•task creators can reconcile submitted work;

•evidence is traceable;

•knowledge proposals preserve provenance;

•permissions are tested;

•audit history is complete;

•telemetry is present;

•tests pass;

•migration and rollback procedures are documented;

•architecture indexes and registries are updated;

•changelog and NEXT.md are updated;

•no unapproved duplicate capability has been introduced;

•a final verification report documents what was built, reused, extended, deferred, and not completed.

Begin with architecture discovery and duplication analysis.

Do not immediately scaffold a new app.

Do not assume the absence of a capability because its name differs.

Do not create parallel task, evidence, document, identity, notification, workflow, or knowledge systems.

Strengthen the Good Combinator platform by implementing one reusable Task Completion capability and proving it through the Point Preserve reference implementation.

The desired outcome is a system in which a person can photograph a problem, explain it by voice, create and assign structured work, track execution, verify the result, and preserve what was learned as reusable operational knowledge—without fragmenting the canonical Good Combinator architecture.