Useful, I guess, but that seems to be inverting the responsibility. The code needs to have comments inserted into it referring to the state of Jira, rather than the other way around.
The thing I'd like to see is that ticket "Write the login page" is automatically marked complete when the codebase contains a working login page, there are unit and integration tests for the login page, and maybe (depending on how you do your documentation) a set of comments on the API methods involved describing their use in the login process. All without those code elements ever needing to know the ticket exists.
What you're describing looks like magic to me. How would your ticket system know, without it being told (in some way, e.g. through backreferences from the tests), that a particular feature has been implemented? That's very likely going to be a formally undecidable problem.
Writing end-to-end UI tests to validate a certain behavior and then automatically resolving a ticket once those tests pass seems really cool though. Not sure how realistic in practice, but it's definitely an interesting concept.
yeah, something like TDD but the ticket is actually a set of integration or end-to-end tests that must pass for the ticket to be "done". Hmmm, interesting...
edit: actually, thinking about it, you could do plain TDD and track the tests as the tickets. Write all your tests for the project first, then track how many are passing as the progress measure.
The thing I'd like to see is that ticket "Write the login page" is automatically marked complete when the codebase contains a working login page, there are unit and integration tests for the login page, and maybe (depending on how you do your documentation) a set of comments on the API methods involved describing their use in the login process. All without those code elements ever needing to know the ticket exists.