Skip to content

✨ Feedbacks & Suggestions #32

Open
Open
✨ Feedbacks & Suggestions#32
Labels
feedbacks

Description

@pedronauck
pedronauck
opened on Apr 3, 2026

Share your feedback and suggestions

This is an open space for the community to share feedback, ideas, and feature suggestions for Compozy.

We'd love to hear from you:

  • What do you like or dislike about the current experience?
  • What features or improvements would you like to see?
  • Any workflow ideas that could make Compozy more useful?

How to contribute

Simply leave a comment below with your thoughts. Be as detailed as you'd like — context helps us prioritize better.

Bug reports don't belong here

If you've found a bug, error, or unexpected behavior, please do not post it here. Instead, open a new issue with steps to reproduce the problem. Bug reports mixed into this thread will be harder to track and may get lost.

TL;DR:

Activity

  1. pedronauck
    added
    feedbacks
    on Apr 3, 2026
  2. pedronauck
    changed the title [-]Feedbacks & Suggestions[/-] [+]✨ Feedbacks & Suggestions[/+] on Apr 3, 2026
  3. pedronauck
    pinned this issue on Apr 3, 2026

  4. rodrigobranas commented on Apr 3, 2026

    @rodrigobranas
    rodrigobranas
    on Apr 3, 2026

    I suggest removing the step-by-step approval for the PRD and Tech Spec. Instead, generate the full preview first and ask for changes at the end. I think most people will naturally click “Next, Next, Finish” and only review everything afterward.

  5. camopy commented on Apr 4, 2026

    @camopy
    camopy
    on Apr 4, 2026
    Contributor

    I suggest removing the step-by-step approval for the PRD and Tech Spec. Instead, generate the full preview first and ask for changes at the end. I think most people will naturally click “Next, Next, Finish” and only review everything afterward.

    Maybe make this optional. This was one of the things I noticed I enjoyed more compared to the previous Compozy

  6. zamorano-dev commented on Apr 5, 2026

    @zamorano-dev
    zamorano-dev
    on Apr 5, 2026

    I suggest removing the step-by-step approval for the PRD and Tech Spec. Instead, generate the full preview first and ask for changes at the end. I think most people will naturally click “Next, Next, Finish” and only review everything afterward.

    I kind of liked that new way of confirmation. So I agree with @camopy in making it optional being the best solution

  7. brunomguimaraes commented on Apr 14, 2026

    @brunomguimaraes
    brunomguimaraes
    on Apr 14, 2026
    Contributor

    I'd like to have some sort of feedback when at the end of a lifecycle. Simple sound could work.
    I've drafted something here

  8. iagowp-mthr commented on Apr 30, 2026

    @iagowp-mthr
    iagowp-mthr
    on Apr 30, 2026

    The link to create a new issue is broken

  9. antoniofulg commented on May 12, 2026

    @antoniofulg
    antoniofulg
    on May 12, 2026
    Contributor

    EDIT: I noticed the .compozy folder should be in the .gitignore, right? This suggestion doesn't make sense.

    What about supporting a counter code prefix for the tasks? I manually added a number as a prefix for the folders, and the IA starts working. But it would be simpler if we could refer to the tasks/reviews by the task/ticket number in the config file:

    [defaults]
tasks_prefix="T-{n}"
    .compozy/tasks/T-1-my-first-task
.compozy/tasks/T-2-my-second-task
.compozy/tasks/T-3-my-third-task

    compozy reviews fix T003
    compozy tasks run T004

  10. MatheusBBarni commented on May 17, 2026

    @MatheusBBarni
    MatheusBBarni
    on May 17, 2026
    Contributor

    I'm working in a feature for running multiples tasks in the same command, like this: compozy tasks run-multiple <task_slug_1>,<task_slug_2>,<task_slug_NN>. The idea for the v1 is run in sequence, and for the v2 to make it run in parallel, but with git worktrees, I would like to know if its valid or not for me to continue. Here you can find the PRD and TechSpec: multi-task-run

  11. rjsoux commented on Jun 11, 2026

    @rjsoux
    rjsoux
    on Jun 11, 2026

    Title: Parallel runs across projects — the one thing forcing me to step away (for now)

    Hi! First, congratulations on Compozy. I'm a solo founder running several ventures, and I've used Compozy end-to-end (PRD → TechSpec → Tasks → Execution → Reviews) on a number of small projects with great success. The artifact-first, markdown-everywhere design is exactly how I believe AI-assisted development should work, and the workflow memory system is genuinely underrated. So thank you for building this.

    That said, I've hit one limitation that is, unfortunately, forcing me to pause my use of Compozy — and I wanted to explain it properly rather than just disappear, because I'd love to come back.

    My use case

    I run multiple small, fully independent projects (separate repos, separate workspaces). To save wall-clock time, I run them in parallel — each one is its own Compozy workflow, executed by Claude Code. Individually, each run works beautifully. Together, they don't.

    What I observed

    When I start runs from different repos at the same time, they all hit the same daemon and serialize. I dug into why:

    • The daemon is a singleton per $HOME. I verified empirically that compozy daemon status from three different directories (two unrelated repos plus /tmp) reports the same socket: ~/.compozy/daemon/daemon.sock. So separate repos, tmux sessions, or git worktrees don't help — they all talk to the same engine.
    • Worse, a second concurrent start from a different workspace didn't queue gracefully in my case — it failed with Internal Server Error, which made me lose track of runs a few times.

    Reading the source, I found that this seems intentional-for-now rather than an oversight:

    • internal/core/workspace/config_types.go already defines both TaskRunMultipleModeEnqueued and TaskRunMultipleModeParallel, and config validation accepts parallel as a valid value.
    • But internal/daemon/task_multi.go currently rejects it with parallel run_multiple mode is not supported by the daemon; use enqueued.
    • Meanwhile RunManager already tracks multiple active runs (ActiveRunCount, ActiveRunCountsByMode), so the skeleton for concurrency appears to be in place.

    In other words: it looks like you've already designed the door — it just isn't open yet. That's actually what makes me optimistic enough to write this.

    What I'm asking for (two tiers)

    Tier 1 — small lift, unblocks me immediately: an official COMPOZY_HOME environment variable (or --home flag) to override the home directory resolved in internal/config/home.go. Today I work around the singleton with a "mirror home" (a fake $HOME that symlinks everything except .compozy), which works because os.UserHomeDir() reads $HOME on Unix — but that's an unsupported hack that could silently break on any release. An official override would let users run one daemon per project deliberately, with a stable contract. I'd guess this is a small change, and I'd be happy to submit a PR for it (with tests following the existing home_test.go patterns) if you're open to the approach.

    Tier 2 — the real fix: implement the parallel mode the schema already promises, so a single daemon can execute runs from independent workspaces concurrently. Even a conservative version (parallelism across workspaces only, keeping per-workspace runs enqueued) would cover my entire use case and, I suspect, that of many solo builders juggling several small projects.

    And independently of both: if concurrency isn't supported yet, a clear 409 Conflict / "run queued behind X" response instead of Internal Server Error would make the current behavior much easier to live with.

    Where I stand

    For now I have to move my parallel workloads elsewhere, which I'm genuinely not happy about — nothing else I've evaluated matches Compozy's spec pipeline. I'll keep the project starred and watched, I'm glad to beta-test any branch that touches this, and as said above, I'm willing to contribute the Tier 1 PR myself if you'd accept it.

    Thanks again for the tool — looking forward to coming back.

  12. rafiti052 commented on Jun 18, 2026

    @rafiti052
    rafiti052
    on Jun 18, 2026

    I suggest removing the step-by-step approval for the PRD and Tech Spec. Instead, generate the full preview first and ask for changes at the end. I think most people will naturally click “Next, Next, Finish” and only review everything afterward.

    Additional to this, I noticed sometimes the prd and tech-spech are not shown anywhere to the user when the final approval is asked, since the agents need aproval before saving the .md file. I was working on a similar tool when I discovered compozy and will try to create a pull request on this idea and submit it for discussion.

  13. andreustimm commented on Jun 24, 2026

    @andreustimm
    andreustimm
    on Jun 24, 2026

    Hi Pedro, I'm from Brazil, and I have a couple of questions.

    Do we have the feature to work with Git worktrees in Compozy today?

    Is there a timeline for releasing this feature?

    Do you need help building it?

  14. pedronauck commented on Jun 26, 2026

    @pedronauck
    pedronauck
    on Jun 26, 2026
    MemberAuthor

    Hi Pedro, I'm from Brazil, and I have a couple of questions.

    Do we have the feature to work with Git worktrees in Compozy today?

    Is there a timeline for releasing this feature?

    Do you need help building it?

    Hi Andre, yes for sure, it's about to be released a new worktree feature indeed.

  15. pedronauck
    added a commit that references this issue on Jul 2, 2026

    feat: support COMPOZY_HOME env override for home directory (#216)

    73ced7f

  16. pedrotecinf commented on Aug 12, 2026

    @pedrotecinf
    pedrotecinf
    on Aug 12, 2026

    Suporte a anexar imagens na sessão de chat

    Seria muito útil poder anexar imagens diretamente na sessão de chat do Compozy (durante a interação com o agente), e não apenas nos comentários do GitHub. Isso ajudaria bastante em casos como:

    • Enviar screenshots de erros, stack traces ou comportamentos inesperados da UI para o agente analisar visualmente.
    • Anexar diagramas de arquitetura, wireframes ou mockups como referência ao gerar PRD/TechSpec.
    • Compartilhar prints de logs, dashboards ou telas de terceiros que não podem ser copiados como texto.
    • Dar contexto visual para tarefas de front-end (ex: "implemente esse layout" com print da imagem anexa).

    Como sugestão de implementação: suporte a drag-and-drop ou paste de imagem no input do chat (similar ao GitHub), com o agente processando via modelo multimodal (Claude, GPT-4V, etc.) quando disponível. Isso se encaixaria bem no fluxo baseado em artefatos/Markdown que já existe, já que a imagem poderia ser salva como referência dentro do workspace do task.

  17. rjsoux commented on Aug 12, 2026

    @rjsoux
    rjsoux
    on Aug 12, 2026

    Hi Pedro, congrats on Compozy!

    In the Aug 10 stream I saw the Tailscale extension for connecting machines. Any chance of supporting WireGuard too? I ran into some issues with Tailscale on my Mac and prefer plain WireGuard.

    Thanks!

  18. pedronauck commented on Aug 12, 2026

    @pedronauck
    pedronauck
    on Aug 12, 2026
    MemberAuthor

    Hi Pedro, congrats on Compozy!

    In the Aug 10 stream I saw the Tailscale extension for connecting machines. Any chance of supporting WireGuard too? I ran into some issues with Tailscale on my Mac and prefer plain WireGuard.

    Thanks!

    Of course, can you please open an issue 🙏🏻

  19. pedronauck commented on Aug 12, 2026

    @pedronauck
    pedronauck
    on Aug 12, 2026
    MemberAuthor

    Suporte a anexar imagens na sessão de chat

    Seria muito útil poder anexar imagens diretamente na sessão de chat do Compozy (durante a interação com o agente), e não apenas nos comentários do GitHub. Isso ajudaria bastante em casos como:

    • Enviar screenshots de erros, stack traces ou comportamentos inesperados da UI para o agente analisar visualmente.
    • Anexar diagramas de arquitetura, wireframes ou mockups como referência ao gerar PRD/TechSpec.
    • Compartilhar prints de logs, dashboards ou telas de terceiros que não podem ser copiados como texto.
    • Dar contexto visual para tarefas de front-end (ex: "implemente esse layout" com print da imagem anexa).

    Como sugestão de implementação: suporte a drag-and-drop ou paste de imagem no input do chat (similar ao GitHub), com o agente processando via modelo multimodal (Claude, GPT-4V, etc.) quando disponível. Isso se encaixaria bem no fluxo baseado em artefatos/Markdown que já existe, já que a imagem poderia ser salva como referência dentro do workspace do task.

    Ótimo sugestão @pedrotecinf você poderia abrir uma issue com ela?

  20. GabrielKifer commented on Aug 14, 2026

    @GabrielKifer
    GabrielKifer
    on Aug 14, 2026
    Contributor

    Aqui do lado Windows da força, só esperando a vez pra usar essa maravilha 😅 @pedronauck

  21. pedronauck
    added this to CompozyOS Devand CompozyOS Devon Aug 14, 2026
  22. github-project-automation
    moved this to Todo in CompozyOS Devon Aug 14, 2026

  23. jillesmc commented on Sep 9, 2026

    @jillesmc
    jillesmc
    on Sep 9, 2026

    Hi Pedro. A process question rather than a suggestion, and I would rather ask it here than guess.

    Over the past days I ran a structured comparison of agent-orchestration tools with CompozyOS as one of
    them, on a dedicated Linux box, and it surfaced eight findings on 0.3.0-beta.23. I filed them a few
    minutes ago, routing each one by what your own configuration says. ISSUE_TEMPLATE/config.yml states the issue tracker
    is for bugs and planned work, and the feature template says to start in Ideas while an idea is still taking
    shape:

    Discussions has no other threads, so I suspect those two are easy to miss. That is the main reason for
    this comment.

    And the question: was that the routing you would have wanted? If you would rather have the whole set as
    a single thread, batched differently, prioritised by what actually matters to you, or closed entirely, say
    so and I will do it. I have no attachment to the current shape. I am happy to re-run any measurement with
    a different arrangement, and to open a pull request for any of them.

    Three further findings I held back deliberately: one only bites installs that use the review trail for
    approvals, one I cannot reproduce on the latest release so it fails your own checklist, and one is going to
    the private security channel rather than a public issue.

    Thanks for building this in the open. The --dry-run provenance output and compozy doctor were what
    made several of these findings possible to state precisely instead of vaguely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feedbacks

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions