docs: remove archived legacy material
This commit is contained in:
@@ -1,5 +0,0 @@
|
|||||||
<wpf:ResourceDictionary xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
|
|
||||||
xmlns:s="clr-namespace:System;assembly=mscorlib"
|
|
||||||
xmlns:wpf="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
|
|
||||||
xml:space="preserve">
|
|
||||||
<s:Boolean x:Key="/Default/UserDictionary/Words/=hutopy/@EntryIndexedValue">True</s:Boolean></wpf:ResourceDictionary>
|
|
||||||
@@ -28,13 +28,6 @@ This folder contains the project documentation used to guide product, implementa
|
|||||||
- [FEATURES/organizations.md](/home/jbourdon/repos/social-media/docs/FEATURES/organizations.md): organization account boundary, membership, billing, connectors, and workspace ownership.
|
- [FEATURES/organizations.md](/home/jbourdon/repos/social-media/docs/FEATURES/organizations.md): organization account boundary, membership, billing, connectors, and workspace ownership.
|
||||||
- [BACKLOG.md](/home/jbourdon/repos/social-media/docs/BACKLOG.md): deferred technical and product work.
|
- [BACKLOG.md](/home/jbourdon/repos/social-media/docs/BACKLOG.md): deferred technical and product work.
|
||||||
|
|
||||||
## Archived
|
|
||||||
|
|
||||||
- [archive/PLAN.md](/home/jbourdon/repos/social-media/docs/archive/PLAN.md): early pivot plan.
|
|
||||||
- [archive/SOCIALIZE.md](/home/jbourdon/repos/social-media/docs/archive/SOCIALIZE.md): original consolidated product brief.
|
|
||||||
- [archive/Stripe.md](/home/jbourdon/repos/social-media/docs/archive/Stripe.md): legacy Hutopy monetization notes.
|
|
||||||
- [archive/WORKSHEET.md](/home/jbourdon/repos/social-media/docs/archive/WORKSHEET.md): historical transition worksheet.
|
|
||||||
|
|
||||||
## Root Docs
|
## Root Docs
|
||||||
|
|
||||||
- [README.md](/home/jbourdon/repos/social-media/README.md): repository overview and local development setup.
|
- [README.md](/home/jbourdon/repos/social-media/README.md): repository overview and local development setup.
|
||||||
|
|||||||
@@ -1,431 +0,0 @@
|
|||||||
# PLAN
|
|
||||||
|
|
||||||
> Historical planning snapshot. This document reflects the early product-pivot plan and is not the source of truth for the current implementation state.
|
|
||||||
|
|
||||||
## Purpose
|
|
||||||
|
|
||||||
This document defines the build plan to close the gap between the current codebase and the target product described in [SOCIALIZE.md](/home/jbourdon/repos/social-media/docs/archive/SOCIALIZE.md).
|
|
||||||
|
|
||||||
The current repository is a dead `Hutopy` codebase. The target product, temporarily named `Socialize`, is a workflow application for social media content review, revision, approval, and readiness for publication.
|
|
||||||
|
|
||||||
This is a full product pivot, not a gradual feature expansion.
|
|
||||||
|
|
||||||
## Goal
|
|
||||||
|
|
||||||
Build a product that becomes the system of workflow for:
|
|
||||||
|
|
||||||
- internal content review
|
|
||||||
- provider collaboration
|
|
||||||
- client approval
|
|
||||||
- version tracking
|
|
||||||
- audit trail
|
|
||||||
- notification-driven progress
|
|
||||||
- publication readiness handoff
|
|
||||||
|
|
||||||
The first version should solve the approval pain cleanly before deeper integrations or scheduling features are added.
|
|
||||||
|
|
||||||
## Gap Summary
|
|
||||||
|
|
||||||
### Current Codebase
|
|
||||||
|
|
||||||
The current repository contains:
|
|
||||||
|
|
||||||
- backend modular structure with FastEndpoints and Entity Framework Core
|
|
||||||
- authentication and infrastructure foundations
|
|
||||||
- file storage patterns
|
|
||||||
- frontend Vue application shell
|
|
||||||
- legacy business modules centered on creators, tipping, memberships, and creator-facing experiences
|
|
||||||
|
|
||||||
### Target Product
|
|
||||||
|
|
||||||
The target product needs:
|
|
||||||
|
|
||||||
- workspace and client management
|
|
||||||
- provider and internal team collaboration
|
|
||||||
- content item lifecycle management
|
|
||||||
- asset and revision tracking
|
|
||||||
- comments and approval workflow
|
|
||||||
- workflow events and notifications
|
|
||||||
- client-facing review portal
|
|
||||||
- Google Drive-centered asset ownership
|
|
||||||
- billing readiness for a future Software as a Service offering
|
|
||||||
|
|
||||||
### Core Gap
|
|
||||||
|
|
||||||
The codebase has technical scaffolding that can be reused, but the business domain is largely wrong for the target product.
|
|
||||||
|
|
||||||
The main gap is not infrastructure. The main gap is domain shape, frontend surface, and workflow behavior.
|
|
||||||
|
|
||||||
## Build Principles
|
|
||||||
|
|
||||||
1. Reuse technical foundations when they help, but do not keep old business concepts for convenience.
|
|
||||||
2. Keep the modular backend structure.
|
|
||||||
3. Prefer clean domain language from day one over transitional naming.
|
|
||||||
4. Build around Google Drive ownership first, not direct-upload-first assumptions.
|
|
||||||
5. Deliver one vertical workflow before broad integrations.
|
|
||||||
6. Remove legacy Hutopy product concepts early to reduce semantic drag.
|
|
||||||
7. Keep changes reviewable and validate each phase before widening scope.
|
|
||||||
|
|
||||||
## Keep, Replace, Remove
|
|
||||||
|
|
||||||
### Keep
|
|
||||||
|
|
||||||
- ASP.NET Core backend shell
|
|
||||||
- FastEndpoints setup
|
|
||||||
- modular registration pattern
|
|
||||||
- Entity Framework Core with per-module context where useful
|
|
||||||
- infrastructure wiring
|
|
||||||
- authentication foundation if it can be adapted cleanly
|
|
||||||
- payment infrastructure patterns and Stripe integration capability for future billing
|
|
||||||
- blob or file-handling patterns that still apply
|
|
||||||
- Vue, Vite, Pinia, router, and API client shell
|
|
||||||
- deployment workflows if still useful for the new product
|
|
||||||
|
|
||||||
### Replace
|
|
||||||
|
|
||||||
- domain module set
|
|
||||||
- route design
|
|
||||||
- data model
|
|
||||||
- frontend information architecture
|
|
||||||
- user flows
|
|
||||||
- branding and product language
|
|
||||||
|
|
||||||
### Remove
|
|
||||||
|
|
||||||
- creator domain concepts
|
|
||||||
- creator public profile features
|
|
||||||
- creator monetization flows
|
|
||||||
- Hutopy naming across code and frontend copy
|
|
||||||
- dead UI components and stores tied only to the old product
|
|
||||||
|
|
||||||
### Retire And Rebuild
|
|
||||||
|
|
||||||
- old tipping business flows
|
|
||||||
- old membership business flows
|
|
||||||
- creator-specific Stripe onboarding flows
|
|
||||||
- payment routes and models that are tightly coupled to the dead Hutopy business model
|
|
||||||
|
|
||||||
Keep the underlying payment capability, but rebuild the business-facing billing model around the new product when pricing and subscription design are ready.
|
|
||||||
|
|
||||||
## Target Product Scope For Version 1
|
|
||||||
|
|
||||||
Version 1 should own this workflow:
|
|
||||||
|
|
||||||
1. Internal team creates a content item.
|
|
||||||
2. Assets are linked from Google Drive.
|
|
||||||
3. Publication message and metadata are attached.
|
|
||||||
4. Internal reviewer or provider receives a request.
|
|
||||||
5. Comments and revisions happen in one place.
|
|
||||||
6. Client receives a review request.
|
|
||||||
7. Client approves, rejects, or requests changes.
|
|
||||||
8. Item becomes ready for publishing handoff.
|
|
||||||
|
|
||||||
Not version 1:
|
|
||||||
|
|
||||||
- full scheduling engine
|
|
||||||
- full social publishing
|
|
||||||
- advanced third-party synchronization
|
|
||||||
- analytics suite
|
|
||||||
- full digital asset management platform
|
|
||||||
- full creative production tooling
|
|
||||||
- customer billing and subscription management user flows
|
|
||||||
|
|
||||||
## Target Backend Module Map
|
|
||||||
|
|
||||||
Recommended backend modules:
|
|
||||||
|
|
||||||
- `Identity`
|
|
||||||
- users, authentication, internal roles
|
|
||||||
- `Workspaces`
|
|
||||||
- agencies or operating teams
|
|
||||||
- `Clients`
|
|
||||||
- brands, creators, businesses served by a workspace
|
|
||||||
- `Providers`
|
|
||||||
- external production partners
|
|
||||||
- `Projects`
|
|
||||||
- grouped bodies of work for a client, which may later contain campaign concepts if needed
|
|
||||||
- `ContentItems`
|
|
||||||
- reviewable units with metadata, copy, due dates, and status
|
|
||||||
- `Assets`
|
|
||||||
- asset references, Google Drive linkage, versions, previews
|
|
||||||
- `Approvals`
|
|
||||||
- review requests, approvers, decisions, status transitions
|
|
||||||
- `Comments`
|
|
||||||
- threads, replies, resolution state, contextual discussion
|
|
||||||
- `Notifications`
|
|
||||||
- workflow events, reminders, delivery preferences
|
|
||||||
|
|
||||||
Possible later modules:
|
|
||||||
|
|
||||||
- `Campaigns`
|
|
||||||
- `Calendars`
|
|
||||||
- `Integrations`
|
|
||||||
- `Publishing`
|
|
||||||
- `Analytics`
|
|
||||||
- `Billing`
|
|
||||||
|
|
||||||
## Target Frontend Surface
|
|
||||||
|
|
||||||
Recommended frontend areas:
|
|
||||||
|
|
||||||
- authentication
|
|
||||||
- workspace switcher or workspace context
|
|
||||||
- client list
|
|
||||||
- project list
|
|
||||||
- review queue dashboard
|
|
||||||
- content item detail page
|
|
||||||
- revision and comment timeline
|
|
||||||
- approval status panel
|
|
||||||
- notification center
|
|
||||||
- external client review portal
|
|
||||||
|
|
||||||
Later frontend areas:
|
|
||||||
|
|
||||||
- calendar view
|
|
||||||
- integration settings
|
|
||||||
- publishing handoff dashboard
|
|
||||||
- workflow analytics
|
|
||||||
|
|
||||||
## Proposed Data Backbone
|
|
||||||
|
|
||||||
### Content Item
|
|
||||||
|
|
||||||
A content item should carry:
|
|
||||||
|
|
||||||
- title
|
|
||||||
- publication message
|
|
||||||
- notes
|
|
||||||
- project
|
|
||||||
- client
|
|
||||||
- creator or brand context where relevant
|
|
||||||
- publication targets
|
|
||||||
- publication dates by network when relevant
|
|
||||||
- due date
|
|
||||||
- current status
|
|
||||||
- current active revision set
|
|
||||||
|
|
||||||
### Asset
|
|
||||||
|
|
||||||
An asset should carry:
|
|
||||||
|
|
||||||
- asset type
|
|
||||||
- source type
|
|
||||||
- Google Drive file reference
|
|
||||||
- preview metadata
|
|
||||||
- current version
|
|
||||||
- version history
|
|
||||||
|
|
||||||
### Approval Request
|
|
||||||
|
|
||||||
An approval request should carry:
|
|
||||||
|
|
||||||
- target content item
|
|
||||||
- requested reviewers
|
|
||||||
- stage type
|
|
||||||
- sent at
|
|
||||||
- due at
|
|
||||||
- decision state
|
|
||||||
- decision history
|
|
||||||
|
|
||||||
### Notification Event
|
|
||||||
|
|
||||||
A notification event should carry:
|
|
||||||
|
|
||||||
- event type
|
|
||||||
- triggered by
|
|
||||||
- target entity
|
|
||||||
- recipients
|
|
||||||
- delivery status
|
|
||||||
- timestamps
|
|
||||||
|
|
||||||
## Execution Strategy
|
|
||||||
|
|
||||||
### Phase 0: Freeze Product Direction
|
|
||||||
|
|
||||||
Deliverables:
|
|
||||||
|
|
||||||
- validated worksheet in English
|
|
||||||
- optional French mirror of the worksheet
|
|
||||||
- agreed module map
|
|
||||||
- agreed version 1 scope and anti-scope
|
|
||||||
|
|
||||||
Exit criteria:
|
|
||||||
|
|
||||||
- no ambiguity about the first workflow to build
|
|
||||||
- no unresolved disagreement about Google Drive ownership
|
|
||||||
|
|
||||||
### Phase 1: Remove Legacy Product Surface
|
|
||||||
|
|
||||||
Goals:
|
|
||||||
|
|
||||||
- reduce confusion from Hutopy concepts
|
|
||||||
- make the codebase ready for the new domain
|
|
||||||
|
|
||||||
Work:
|
|
||||||
|
|
||||||
- remove or retire legacy frontend views tied to creators, tipping, and memberships
|
|
||||||
- remove legacy backend modules that are clearly dead
|
|
||||||
- rename product-facing strings, assets, and configuration references
|
|
||||||
- identify infrastructure pieces that stay
|
|
||||||
- preserve Stripe and payment infrastructure that can support future Software as a Service billing
|
|
||||||
- identify backend modules that should be replaced instead of adapted
|
|
||||||
|
|
||||||
Exit criteria:
|
|
||||||
|
|
||||||
- codebase no longer communicates the old product direction
|
|
||||||
- remaining code clearly supports reuse or is queued for replacement
|
|
||||||
|
|
||||||
### Phase 2: Establish New Domain Skeleton
|
|
||||||
|
|
||||||
Goals:
|
|
||||||
|
|
||||||
- introduce the new product vocabulary into code
|
|
||||||
- prepare clean module boundaries
|
|
||||||
|
|
||||||
Work:
|
|
||||||
|
|
||||||
- create new backend modules
|
|
||||||
- define initial entities and contexts
|
|
||||||
- wire modules in `Program.cs`
|
|
||||||
- define route namespaces and tags
|
|
||||||
- create frontend route skeleton for the new product
|
|
||||||
- define new stores for auth, workspace context, review queue, and content items
|
|
||||||
|
|
||||||
Exit criteria:
|
|
||||||
|
|
||||||
- application compiles with the new module map in place
|
|
||||||
- legacy domain is no longer the center of the app
|
|
||||||
|
|
||||||
### Phase 3: Build The First Vertical Slice
|
|
||||||
|
|
||||||
Vertical slice:
|
|
||||||
|
|
||||||
- create content item
|
|
||||||
- link Google Drive asset
|
|
||||||
- add publication message and publication target data
|
|
||||||
- request internal review
|
|
||||||
- comment on item
|
|
||||||
- request changes
|
|
||||||
- upload or register a new revision
|
|
||||||
- request client review
|
|
||||||
- approve from client portal
|
|
||||||
- mark ready to publish
|
|
||||||
|
|
||||||
Backend work:
|
|
||||||
|
|
||||||
- commands and queries for content item creation and retrieval
|
|
||||||
- asset linkage and versioning
|
|
||||||
- comment creation and retrieval
|
|
||||||
- approval request and decision endpoints
|
|
||||||
- status transition logic
|
|
||||||
- workflow event emission
|
|
||||||
|
|
||||||
Frontend work:
|
|
||||||
|
|
||||||
- content item creation flow
|
|
||||||
- content item detail view
|
|
||||||
- comments panel
|
|
||||||
- approval action UI
|
|
||||||
- status timeline
|
|
||||||
- simple client review page
|
|
||||||
|
|
||||||
Exit criteria:
|
|
||||||
|
|
||||||
- one item can move end-to-end from draft to approved
|
|
||||||
- all actions are traceable in one place
|
|
||||||
|
|
||||||
### Phase 4: Add Notification Backbone
|
|
||||||
|
|
||||||
Goals:
|
|
||||||
|
|
||||||
- make workflow movement visible without manual follow-up
|
|
||||||
|
|
||||||
Work:
|
|
||||||
|
|
||||||
- define notification event types
|
|
||||||
- trigger events on comments, revisions, requests, and decisions
|
|
||||||
- add email notifications
|
|
||||||
- add in-app notification center or lightweight feed
|
|
||||||
- add reminder jobs for pending reviews
|
|
||||||
|
|
||||||
Exit criteria:
|
|
||||||
|
|
||||||
- users are informed when workflow events occur
|
|
||||||
- delayed approvals can be followed without manual chasing
|
|
||||||
|
|
||||||
### Phase 5: Harden Version 1 For Real Usage
|
|
||||||
|
|
||||||
Goals:
|
|
||||||
|
|
||||||
- make the workflow usable for the first real client
|
|
||||||
|
|
||||||
Work:
|
|
||||||
|
|
||||||
- permissions and role hardening
|
|
||||||
- validation and error handling
|
|
||||||
- audit trail review
|
|
||||||
- filtering and dashboard improvements
|
|
||||||
- comment resolution
|
|
||||||
- required approver logic if needed
|
|
||||||
- publication dates by network support
|
|
||||||
- quality pass on mobile review experience
|
|
||||||
|
|
||||||
Exit criteria:
|
|
||||||
|
|
||||||
- the first client can run a real approval cycle in the product
|
|
||||||
|
|
||||||
### Phase 6: Evaluate Phase 2 Expansion
|
|
||||||
|
|
||||||
Candidates:
|
|
||||||
|
|
||||||
- calendar visibility
|
|
||||||
- Google Drive sync improvements
|
|
||||||
- Canva linkage
|
|
||||||
- MailChimp approval path
|
|
||||||
- scheduler handoff integrations
|
|
||||||
- billing and subscription management for the Software as a Service offer
|
|
||||||
|
|
||||||
Rule:
|
|
||||||
|
|
||||||
Only start these after version 1 workflow is demonstrably useful.
|
|
||||||
|
|
||||||
## Immediate Technical Tasks
|
|
||||||
|
|
||||||
Recommended next implementation tasks:
|
|
||||||
|
|
||||||
1. Rename the product and remove visible Hutopy branding.
|
|
||||||
2. Inventory which backend modules are deleted versus replaced.
|
|
||||||
3. Define the new backend module directories and initial project structure.
|
|
||||||
4. Replace the frontend router with the new application surface.
|
|
||||||
5. Model `ContentItem`, `Asset`, `AssetVersion`, `ApprovalRequest`, `ApprovalDecision`, `CommentThread`, and `NotificationEvent`.
|
|
||||||
6. Implement the first vertical slice end to end.
|
|
||||||
|
|
||||||
## Risks
|
|
||||||
|
|
||||||
- scope creep into scheduling and publishing too early
|
|
||||||
- forcing the new domain into old creator-centric structures
|
|
||||||
- under-designing workflow status and revision semantics
|
|
||||||
- overbuilding integrations before the core workflow is proven
|
|
||||||
- making external review too heavy for clients
|
|
||||||
|
|
||||||
## Validation Checklist
|
|
||||||
|
|
||||||
Before claiming version 1 readiness:
|
|
||||||
|
|
||||||
- a workspace can manage at least one client
|
|
||||||
- a content item can include publication message and publication targets
|
|
||||||
- assets can be linked from Google Drive
|
|
||||||
- internal review can request changes
|
|
||||||
- client review can approve or reject
|
|
||||||
- status history is visible
|
|
||||||
- notification events are triggered
|
|
||||||
- the latest approved state is clear
|
|
||||||
|
|
||||||
## Working Note
|
|
||||||
|
|
||||||
This plan should be updated as soon as the first implementation decisions are made, especially:
|
|
||||||
|
|
||||||
- exact module names
|
|
||||||
- exact database boundaries
|
|
||||||
- whether `Providers` stands alone or is modeled as a participant role
|
|
||||||
- whether notifications are their own module or an infrastructure concern
|
|
||||||
@@ -1,328 +0,0 @@
|
|||||||
# Social Media Approval Workflow
|
|
||||||
|
|
||||||
Temporary product name: `Socialize`
|
|
||||||
|
|
||||||
## Project Intent
|
|
||||||
|
|
||||||
Build `Socialize`, an application that replaces the current approval process based on Google Drive, phone calls, emails, and spreadsheets.
|
|
||||||
|
|
||||||
The product is not a public social network. It is an internal/external workflow tool for content review, feedback, approval, and publication readiness.
|
|
||||||
|
|
||||||
## Shared Vocabulary
|
|
||||||
|
|
||||||
- Approval workflow: the end-to-end process from draft creation to final approval.
|
|
||||||
- Content item: the reviewable unit that bundles assets, publication message or copy, dates, and channel targets.
|
|
||||||
- Asset: a file attached to a content item, such as a video, image, or document.
|
|
||||||
- Revision: a new version of an asset or copy after feedback.
|
|
||||||
- External reviewer: a client or partner who reviews content without being part of the internal team.
|
|
||||||
- Provider: an external production partner, such as a film crew, photographer, editor, or designer, who may deliver drafts and receive change requests.
|
|
||||||
- Software as a Service (SaaS): a cloud-based product used through the web, such as Canva, MailChimp, HootSuite, or Metricool.
|
|
||||||
- Minimum Viable Product (MVP): the smallest product version that solves the main pain point well enough to validate the market.
|
|
||||||
- Service Level Agreement (SLA): an agreed service target, such as a review deadline or escalation threshold.
|
|
||||||
|
|
||||||
## Problem Statement
|
|
||||||
|
|
||||||
Social media managers and production teams currently manage content approvals manually:
|
|
||||||
|
|
||||||
- Assets are stored in Google Drive.
|
|
||||||
- The social media manager may have back-and-forth with both upstream providers and downstream clients.
|
|
||||||
- Feedback is exchanged by phone, email, messages, and spreadsheets.
|
|
||||||
- Version history is unclear.
|
|
||||||
- It is hard to know which file is the latest one.
|
|
||||||
- Comments are scattered across multiple channels.
|
|
||||||
- Internal approvals and client approvals follow similar patterns but are not centralized.
|
|
||||||
- Follow-ups are manual, so approvals get delayed.
|
|
||||||
|
|
||||||
Result: too much back-and-forth, poor traceability, avoidable delays, and risk of publishing the wrong asset or outdated copy.
|
|
||||||
|
|
||||||
## Existing Tools Observed
|
|
||||||
|
|
||||||
- Google Drive for videos, images, calendars, and documents
|
|
||||||
- Google Sheets or similar for tracking comments and status
|
|
||||||
- Phone and email for review/approval conversations
|
|
||||||
- HootSuite
|
|
||||||
- Metricool
|
|
||||||
- Canva
|
|
||||||
- MailChimp
|
|
||||||
|
|
||||||
## Primary Users
|
|
||||||
|
|
||||||
- Social media manager
|
|
||||||
- Account manager / customer success
|
|
||||||
- Client approver
|
|
||||||
- External provider / production partner
|
|
||||||
- Internal producer
|
|
||||||
- Internal employee / content contributor
|
|
||||||
- Administrator
|
|
||||||
|
|
||||||
## Core Use Cases
|
|
||||||
|
|
||||||
### 1. Client Approval Workflow
|
|
||||||
|
|
||||||
A social media manager prepares content for a client and sends it for approval.
|
|
||||||
|
|
||||||
The client should be able to:
|
|
||||||
|
|
||||||
- view the content package
|
|
||||||
- preview files
|
|
||||||
- read captions, descriptions, and project notes
|
|
||||||
- leave comments
|
|
||||||
- request changes
|
|
||||||
- approve or reject
|
|
||||||
|
|
||||||
The team should be able to:
|
|
||||||
|
|
||||||
- see approval status in real time
|
|
||||||
- answer comments in context
|
|
||||||
- upload revised versions
|
|
||||||
- keep a clear audit trail of who said what and when
|
|
||||||
- know exactly which version is approved
|
|
||||||
|
|
||||||
### 2. Internal Production Workflow
|
|
||||||
|
|
||||||
The same workflow should work internally for producers, employees, and external production partners before the content is shown to the client or scheduled for publishing.
|
|
||||||
|
|
||||||
Example:
|
|
||||||
|
|
||||||
- contributor uploads draft
|
|
||||||
- external provider can upload draft or revised media
|
|
||||||
- producer reviews and requests changes
|
|
||||||
- manager approves for client review
|
|
||||||
- client approves
|
|
||||||
- content is marked ready to publish
|
|
||||||
|
|
||||||
### 3. Content Package Review
|
|
||||||
|
|
||||||
Approval should not be limited to a single file. A review item may include:
|
|
||||||
|
|
||||||
- video
|
|
||||||
- image
|
|
||||||
- document
|
|
||||||
- publication message / caption / copy
|
|
||||||
- hashtags
|
|
||||||
- links
|
|
||||||
- publication dates
|
|
||||||
- target channels or social networks
|
|
||||||
|
|
||||||
## Current Workflow Summary
|
|
||||||
|
|
||||||
Typical current flow:
|
|
||||||
|
|
||||||
1. Team creates media assets.
|
|
||||||
2. Files are placed in Google Drive by the team or by external providers.
|
|
||||||
3. A manager sends links by email or message to providers, internal stakeholders, or clients.
|
|
||||||
4. Feedback comes back by phone, email, spreadsheet, or chat.
|
|
||||||
5. Team manually consolidates comments across provider feedback and client feedback.
|
|
||||||
6. A revised version is uploaded.
|
|
||||||
7. The cycle repeats until someone says it is approved.
|
|
||||||
8. Approval status is manually tracked elsewhere.
|
|
||||||
|
|
||||||
Main failure points:
|
|
||||||
|
|
||||||
- no single source of truth
|
|
||||||
- no structured approval states
|
|
||||||
- no centralized threaded comments
|
|
||||||
- no deadline reminders
|
|
||||||
- no reliable audit trail
|
|
||||||
- no approval gate before publishing
|
|
||||||
|
|
||||||
## Target Workflow
|
|
||||||
|
|
||||||
1. Create a project and associate it with a client.
|
|
||||||
2. Create a review item or approval request.
|
|
||||||
3. Attach assets or import them from Google Drive.
|
|
||||||
4. Add metadata:
|
|
||||||
- title
|
|
||||||
- publication message / caption / copy
|
|
||||||
- target platform or social network
|
|
||||||
- publication dates by network when relevant
|
|
||||||
- due date
|
|
||||||
- reviewer(s)
|
|
||||||
5. Send review request.
|
|
||||||
6. Reviewers comment directly on the item.
|
|
||||||
7. Team or provider uploads a revision or responds to comments.
|
|
||||||
8. System tracks versions, status changes, and workflow events.
|
|
||||||
9. Reviewer approves, rejects, or requests changes.
|
|
||||||
10. Once all required approvals are complete, item becomes ready for scheduling/publishing.
|
|
||||||
|
|
||||||
## Core Domain Objects
|
|
||||||
|
|
||||||
- Workspace: the top-level account boundary for one agency or one operating team.
|
|
||||||
- Client: the business, creator, or brand receiving the service and approving content.
|
|
||||||
- Team member: an internal user working on content, reviews, or coordination.
|
|
||||||
- Reviewer: any person asked to review and approve, whether internal or external.
|
|
||||||
- Provider: an external production contributor such as a photographer, videographer, editor, or designer.
|
|
||||||
- Project: the main work container for a client, grouping related content items, notes, participants, and timelines.
|
|
||||||
- Content item: the reviewable unit that contains assets, publication message, channel targets, due dates, and approval state.
|
|
||||||
- Asset: an attached file, such as a video, image, or document, referenced from Google Drive or stored directly.
|
|
||||||
- Asset version: a specific revision of an asset, with traceability to who uploaded it and when.
|
|
||||||
- Comment thread: a contextual discussion attached to a content item, asset, or revision.
|
|
||||||
- Approval request: the act of asking one or more reviewers to review a specific version.
|
|
||||||
- Approval decision: the outcome of a review request, such as approved, rejected, or changes requested.
|
|
||||||
- Status history: the audit trail of workflow states and transitions over time.
|
|
||||||
- Publication target: the intended destination for publication, such as Instagram, Facebook, LinkedIn, or a newsletter.
|
|
||||||
- Notification event: a workflow event that informs users something changed, such as a new comment, revision, request, or approval.
|
|
||||||
|
|
||||||
## Suggested Status Model
|
|
||||||
|
|
||||||
- Draft
|
|
||||||
- In internal review
|
|
||||||
- Changes requested internally
|
|
||||||
- Internal changes in progress
|
|
||||||
- Ready for client review
|
|
||||||
- In client review
|
|
||||||
- Changes requested by client
|
|
||||||
- Client changes in progress
|
|
||||||
- Approved
|
|
||||||
- Rejected
|
|
||||||
- Ready to publish
|
|
||||||
- Published
|
|
||||||
- Archived
|
|
||||||
|
|
||||||
## Minimum Viable Product (MVP) Scope
|
|
||||||
|
|
||||||
The first version should focus on approval workflow, not direct publishing.
|
|
||||||
|
|
||||||
### MVP Features
|
|
||||||
|
|
||||||
- authentication and user roles
|
|
||||||
- workspace/client/project structure
|
|
||||||
- create a content item with metadata
|
|
||||||
- upload assets or attach Google Drive links while keeping Google Drive as the source of truth when required by the client
|
|
||||||
- version tracking for files and copy
|
|
||||||
- centralized comments
|
|
||||||
- approval decisions: approve, reject, request changes
|
|
||||||
- activity timeline / audit trail
|
|
||||||
- status dashboard by client, project, and due date
|
|
||||||
- notifications and reminders when actions are completed or workflow events occur
|
|
||||||
- simple approval portal for external clients
|
|
||||||
|
|
||||||
### Strong MVP Candidate Features
|
|
||||||
|
|
||||||
- required approvers
|
|
||||||
- approval deadline
|
|
||||||
- due dates per publication target or social network
|
|
||||||
- compare current version vs previous version
|
|
||||||
- "latest approved version" indicator
|
|
||||||
- comment resolution
|
|
||||||
- filtering by status, client, assignee, due date
|
|
||||||
|
|
||||||
## Phase 2 Opportunities
|
|
||||||
|
|
||||||
- Google Drive integration with file sync/import
|
|
||||||
- HootSuite / Metricool export or handoff
|
|
||||||
- Canva asset linking
|
|
||||||
- MailChimp approval workflow for newsletters
|
|
||||||
- calendar integration for publication planning visibility
|
|
||||||
- annotated comments on images or video timestamps
|
|
||||||
- reusable approval templates by content type
|
|
||||||
- Service Level Agreement (SLA) reminders and escalations
|
|
||||||
- analytics on turnaround time and bottlenecks
|
|
||||||
- approval by email link
|
|
||||||
- multi-stage approval rules per client
|
|
||||||
|
|
||||||
## Key Automation Opportunities
|
|
||||||
|
|
||||||
- auto-request approval when a content item reaches a defined stage
|
|
||||||
- automatic notifications when a workflow action is completed or a workflow event occurs
|
|
||||||
- automatic reminders before approval deadlines
|
|
||||||
- automatic escalation when approval is overdue
|
|
||||||
- automatic version labeling
|
|
||||||
- automatic "ready to publish" state when all approvals are complete
|
|
||||||
- automatic audit trail for every upload, comment, and decision
|
|
||||||
- automatic client-facing review link generation
|
|
||||||
- automatic notification when a new revision addresses requested changes
|
|
||||||
|
|
||||||
## Important Product Decisions
|
|
||||||
|
|
||||||
### 1. System of record for assets
|
|
||||||
|
|
||||||
Options:
|
|
||||||
|
|
||||||
- keep Google Drive as file storage and build workflow around it
|
|
||||||
- upload files directly into this new application
|
|
||||||
- support both
|
|
||||||
|
|
||||||
Recommended first assumption:
|
|
||||||
|
|
||||||
Keep Google Drive as the source of truth when the client requires ownership there, and support direct uploads later as an option. The first version should work cleanly with Drive links and imported metadata before deeper synchronization is considered.
|
|
||||||
|
|
||||||
### 2. External reviewer experience
|
|
||||||
|
|
||||||
Options:
|
|
||||||
|
|
||||||
- reviewer account required
|
|
||||||
- magic-link access without full account
|
|
||||||
- both
|
|
||||||
|
|
||||||
Recommended first assumption:
|
|
||||||
|
|
||||||
Use magic-link review access for clients to reduce friction.
|
|
||||||
|
|
||||||
### 3. Approval granularity
|
|
||||||
|
|
||||||
Possible approval units:
|
|
||||||
|
|
||||||
- entire content item
|
|
||||||
- per asset
|
|
||||||
- per caption/copy
|
|
||||||
- per channel variation
|
|
||||||
|
|
||||||
Recommended first assumption:
|
|
||||||
|
|
||||||
Approve at the content item level in the Minimum Viable Product (MVP), with comments attached to assets and copy.
|
|
||||||
|
|
||||||
## Business Rules To Confirm
|
|
||||||
|
|
||||||
These do not block initial scoping, but we should capture them early so the product behavior matches the real approval process.
|
|
||||||
|
|
||||||
- Can a client approve with unresolved comments?
|
|
||||||
- Does approval require one reviewer or multiple reviewers?
|
|
||||||
- Can internal approval and client approval happen in parallel?
|
|
||||||
- Is approval valid only for the latest version?
|
|
||||||
- Can an approved item be edited without reopening review?
|
|
||||||
- Do different clients require different workflows?
|
|
||||||
- Are videos, images, and documents all equally important on day one?
|
|
||||||
- Is scheduling/publishing inside scope, or only "approval-ready" handoff?
|
|
||||||
|
|
||||||
## Open Questions For Next Interview
|
|
||||||
|
|
||||||
- Who is the buyer: agency, freelancer, or in-house marketing team?
|
|
||||||
- Is the first target market agency-to-client approval, internal team approval, or both?
|
|
||||||
- What content types are highest priority: video, image, documents, captions, newsletters?
|
|
||||||
- How often do clients request changes after verbal approval?
|
|
||||||
- What is the most painful step today?
|
|
||||||
- What tools must remain in place at launch?
|
|
||||||
- What approvals need legal or compliance traceability?
|
|
||||||
- How many reviewers usually participate per item?
|
|
||||||
- Is bilingual support required?
|
|
||||||
- Is mobile review important on day one?
|
|
||||||
|
|
||||||
## Minimum Viable Product (MVP) Success Criteria
|
|
||||||
|
|
||||||
- reduce approval turnaround time
|
|
||||||
- reduce back-and-forth across email/phone/spreadsheets
|
|
||||||
- give one clear source of truth for latest version and current status
|
|
||||||
- let a client approve without training
|
|
||||||
- let the team see blocked items instantly
|
|
||||||
|
|
||||||
## Product Positioning
|
|
||||||
|
|
||||||
This product should be positioned as:
|
|
||||||
|
|
||||||
"A review and approval workflow for social media content, not another content creation tool."
|
|
||||||
|
|
||||||
The value is coordination, traceability, and faster approval cycles.
|
|
||||||
|
|
||||||
## First Build Recommendation
|
|
||||||
|
|
||||||
Build the first release around this narrow flow:
|
|
||||||
|
|
||||||
1. team creates content item
|
|
||||||
2. team uploads files and copy
|
|
||||||
3. internal reviewer comments and requests changes
|
|
||||||
4. team submits to client
|
|
||||||
5. client comments and approves via simple link
|
|
||||||
6. item becomes ready for publishing handoff
|
|
||||||
|
|
||||||
If this flow works cleanly, integrations and scheduling can be added later.
|
|
||||||
@@ -1,32 +0,0 @@
|
|||||||
# Stripe
|
|
||||||
|
|
||||||
> Legacy Hutopy-era notes. These flows describe the old creator membership and tipping model and do not match the current workflow product.
|
|
||||||
|
|
||||||
## Events Workflow
|
|
||||||
|
|
||||||
### Membership
|
|
||||||
|
|
||||||
1. checkout.session.completed
|
|
||||||
- Store StripeSubscriptionId, UserId, CreatorId, TierId
|
|
||||||
- Save a new Subscription entity with the status "Pending"
|
|
||||||
|
|
||||||
2. invoice.payment_succeeded
|
|
||||||
- Grant access (set Subscription.Active = true or similar)
|
|
||||||
- Record transaction or set StartDate
|
|
||||||
- Notify Creator (e.g., new member)
|
|
||||||
|
|
||||||
3. customer.subscription.updated
|
|
||||||
- Update `EndDate = CancelAt ?? CanceledAt`
|
|
||||||
|
|
||||||
4. customer.subscription.deleted
|
|
||||||
- Revoke access
|
|
||||||
- Mark Subscription as inactive/ended
|
|
||||||
|
|
||||||
### Tips
|
|
||||||
|
|
||||||
1. checkout.session.completed
|
|
||||||
- Store TipId, StripeSessionId, TipperId, CreatorId
|
|
||||||
- PaymentIntentStatus == "paid"
|
|
||||||
- Status = "Paid"
|
|
||||||
- Notify creator
|
|
||||||
- Record transaction
|
|
||||||
@@ -1,35 +0,0 @@
|
|||||||
> Historical worksheet from the product-pivot phase. Several items are completed, renamed, or superseded by the current codebase.
|
|
||||||
|
|
||||||
What is left to do:
|
|
||||||
|
|
||||||
1. Replace frontend seeded stores with real API-backed stores.
|
|
||||||
2. Build authenticated loading for:
|
|
||||||
- workspaces
|
|
||||||
- clients
|
|
||||||
- projects
|
|
||||||
- content items
|
|
||||||
3. Add create flows:
|
|
||||||
- create workspace
|
|
||||||
- create client
|
|
||||||
- create project
|
|
||||||
- create content item
|
|
||||||
4. Build the first real content-item detail page.
|
|
||||||
5. Add the actual approval workflow domain:
|
|
||||||
- approval requests
|
|
||||||
- approval decisions
|
|
||||||
- status transitions
|
|
||||||
6. Add comments and revision tracking.
|
|
||||||
7. Add Google Drive asset linkage instead of placeholder source fields only.
|
|
||||||
8. Add notification/event backbone.
|
|
||||||
9. Remove or retire old Hutopy modules and routes once the new vertical slice replaces them.
|
|
||||||
10. Rename remaining Hutopy namespaces/product strings in the backend if you want the codebase semantics
|
|
||||||
cleaned up now instead of later.
|
|
||||||
|
|
||||||
|
|
||||||
So the main remaining substantive work is:
|
|
||||||
|
|
||||||
1. finish full-site localization
|
|
||||||
2. build real integrations backend for Google Drive and API keys
|
|
||||||
3. deepen workspace/settings management
|
|
||||||
4. continue workflow polish and broader comment/thread modeling if you want that
|
|
||||||
generalized again
|
|
||||||
@@ -45,5 +45,4 @@ These are cross-cutting rules for the current product and codebase. They are int
|
|||||||
|
|
||||||
## Naming Constraints
|
## Naming Constraints
|
||||||
|
|
||||||
- Prefer current product/domain language over Hutopy-era terminology.
|
|
||||||
- Avoid reviving creator/tipping/membership concepts unless intentionally rebuilding them for the new product.
|
- Avoid reviving creator/tipping/membership concepts unless intentionally rebuilding them for the new product.
|
||||||
|
|||||||
Reference in New Issue
Block a user